What CIP-007-6 R5 system access control asks for and why auditors test it
CIP-007-6 R5 governs how interactive and shared access to in-scope Cyber Assets is authenticated, inventoried and limited. If your audit includes this requirement, expect the assessor to ask who can log in to each in-scope device, how that login is proven, which accounts exist that nobody personally owns, and what stops someone from guessing a password. The requirement has seven parts. Part 5.1 asks you to enforce authentication for interactive user access where the device can technically support it. Parts 5.2 and 5.3 ask you to inventory default and generic accounts and to name the individuals authorized to use shared accounts. Part 5.4 asks you to change known default passwords. Parts 5.5 and 5.6 set minimum password length and complexity for password-only logins and require password changes at least once every 15 calendar months where feasible. Part 5.7 asks you to limit failed login attempts or alert when they pile up.
The risk behind these parts is simple. A default password that ships with a device is public knowledge, a generic account such as an operator login has no owner to answer for its use, and a shared account hides who did what. Auditors test R5 because these weaknesses are easy to exploit and hard to trace afterward. The phrases 'where technically feasible' and 'per Cyber Asset capability' mean the standard does not impose one uniform setting on every device. Whether a password can be length-checked, rotated or locked out depends on what that specific device supports, so the answer for a legacy relay or HMI may differ from the answer for a modern server. Confirm the exact applicability wording in the current standard before you write any device-specific exception.
The work usually gets hard in three places. Legacy devices often have fixed passwords, no account lockout and no way to change credentials without a vendor visit, which forces a documented capability assessment and, where needed, a compensating plan. Shared operator accounts are common because they are convenient on control room consoles, and the named-individual list for them is often missing or stale. Inventories drift because accounts are created locally on devices, outside the central directory, and nobody reconciles them. Start by pulling a current account listing from each in-scope device class, mark each account as default, generic, shared or individual, and record for each one what the device can enforce. That single spreadsheet will drive most of the rest of your R5 evidence. Ask your vendors in writing what each device supports before you assume.
Which systems, accounts and teams R5 applies to
CIP-007-6 R5 does not apply to every device an entity owns. Its Applicable Systems column decides which Cyber Assets must meet each part, so the scoping result from CIP-002 sets most of the work. The four cards below follow that chain from impact rating to the people who run the accounts.
Impact categories and asset types
Start with the CIP-002 list of BES Cyber Systems and their high, medium or low impact ratings. R5 is written in tables by Applicable Systems, so a high impact BES Cyber System, a medium impact system with External Routable Connectivity, and associated EACMS, PACS and PCA may fall into different rows. Confirm each row against your own CIP-002 list and the Regional Entity's guidance before you build the account inventory, because a wrong row means the wrong evidence.
Interactive user access paths
Map every path a person can use to log in interactively. That includes the local console, serial connections, network-based sessions and remote management interfaces such as out-of-band controllers. Part 5.1 asks you to enforce authentication on each path where technically feasible, so an unlisted path is the usual gap in an assessment. Record the path, the device, and whether the login is password-only or uses another method.
Generic and shared accounts
Inventory every enabled default or generic account on operating systems, network devices and applications, including service accounts and vendor-supplied logins. Part 5.2 requires this list, and Part 5.3 requires you to name the individuals who may use each shared account. Devices often carry accounts that no one remembers creating, so run a discovery pass against each device type rather than relying on the original build documents.
Owners of identity and device access
Assign named owners for directory and identity services, vendor accounts and device administration. Identity teams usually own central sign-in, while operations or vendors often hold local administrator logins on field devices. Write down who approves a change to each account, who rotates default passwords under Part 5.4, and who answers for failed-login alerts under Part 5.7. Unclear ownership is where R5 evidence most often breaks down.
How an assessor tests each part of R5
This table compares what an auditor checks for each part of CIP-007-6 R5, the sample they pull, the evidence they expect, and where entities usually fail. Read it as a checklist: population-based parts depend on a complete inventory, while device-level parts depend on per-asset settings and any documented technical feasibility exceptions.
| Requirement part | What the assessor checks | Sample or population requested | Evidence expected | Common findings |
|---|---|---|---|---|
| Scope (Applicable Systems) | Which BES Cyber Systems, EACMS, PACS and PCA fall under R5 for the entity's impact rating | The current BES Cyber System list with impact categories and asset-level applicability | Categorization records from CIP-002 and a mapping of each Applicable System to its R5 controls | Assets added after the last review that were never mapped to R5 |
| 5.1 Enforce authentication of interactive user access | Whether interactive user access to each in-scope device requires authentication, or where it does not, whether that is technically infeasible | Sample of Applicable Systems, including devices with local and remote interactive access | Configuration exports or screenshots showing authentication enforcement, plus feasibility documentation where claimed | Shared logins with no authentication, or feasibility claims with no written basis |
| 5.2 Inventory default and generic accounts | Whether all known enabled default or generic accounts are identified and tracked per device | Full population of accounts on sampled devices, compared against the device list | Account inventory per device showing account name, type, enabled status and owner or purpose | Inventory built from policy rather than the live system; disabled or service accounts omitted |
| 5.3 Identify shared account users | Whether each shared account has a named list of individuals authorized to use it | Shared accounts from the 5.2 inventory, with their authorized user lists | Authorized user list per shared account, with dates and approval records | Shared accounts with no current user list, or lists containing people who have left |
| 5.4 Change known default passwords | Whether known default passwords were changed on each device where the Cyber Asset supports it | Sampled devices, especially newly commissioned or replaced equipment | Change records, vendor default checks, and reasons where a device cannot change the password | Vendor default credentials left in place on new hardware or appliances |
| 5.5 Password length and complexity (password-only access) | Whether password settings meet at least the lesser of eight characters or the device maximum, and the lesser of three character types or the device maximum | Password policy settings for each password-only device or central directory policy that governs it | Screenshots or exports of password policy settings per device or directory, with the device maximum where it applies | Central policy documented but not enforced on local devices; settings that differ across the population |
| 5.6 Password change every 15 calendar months | Whether passwords for password-only interactive access are changed or forced to change at least every 15 calendar months, where technically feasible | Password-only interactive accounts from the inventory, with last change dates | Last-change dates or forced-change settings, and a dated record showing no account exceeds 15 calendar months | Accounts last changed more than 15 calendar months ago, or passwords with no expiry and no feasibility record |
| 5.7 Limit or alert on failed logins | Whether unsuccessful authentication attempts are capped or alerted after a defined threshold, where technically feasible | Sampled devices and the alerting or lockout configuration for each | Lockout settings, alert rules, and sample alerts or event records showing the control operated | Lockout set on some devices only, alerts configured but not routed to a reviewed queue |
How to implement R5 in six steps
This sequence takes an entity from knowing which Cyber Assets fall under CIP-007-6 R5 to a documented, tested set of account and password controls, with the exceptions recorded wherever a device cannot meet a Part as written. Each step produces an artifact an auditor can sample.
Confirm applicable Cyber Assets and authentication methods
Start from the CIP-002 categorization and list the Applicable Systems for R5, which are the high and medium impact BES Cyber Systems, their associated EACMS, PACS and PCA, and any other in-scope assets your categorization identifies. For each asset, record how interactive users sign in today, such as password-only, password with a second factor, or a centralized identity provider. The output is a scoped asset list with an authentication method column, and the check is that every in-scope device has a stated method and an owner who confirmed it. Ask your Compliance Enforcement Authority contact or your auditor which asset types they expect to see in this list before you finalize it.
Enumerate default, generic and shared accounts
On each in-scope Cyber Asset, export the local and directory account lists and identify every enabled default account, generic account and shared account, including service and vendor accounts that remain enabled. Compare the export against vendor documentation so that built-in accounts are not missed. The output is the account inventory, with one row per account showing the asset, account name, account type and whether it is enabled. The check is a second person reconciling the export against the device list, because the inventory is the baseline every later Part is tested against.
Assign owners and record shared-account access
Give every generic and shared account a named owner who is accountable for who uses it and when. For each shared account, record the individuals authorized to use it, linked to their access authorization under CIP-004 so the list can be reconciled against personnel records. Disable any generic or shared account that has no business need. The output is the shared-account register with owner and authorized-user fields, and the check is that each shared account has an owner and a documented user list that matches the inventory from the previous step.
Enforce interactive authentication and change default passwords
Configure each in-scope device so that interactive user access requires authentication, using the device's supported methods, and where the device supports it, route sign-in through a central identity source. Then change every known default password on the device to a value that meets your password standard, or remove the account if it is not needed. Where a device cannot change a default password, record the limitation for the exception step. The output is a device configuration export or screenshot showing enforced authentication, plus a change record for each default account. The check is a test login with each remaining account to confirm the default credential no longer works.
Configure password rules, 15-month changes and failed-login controls
For password-only accounts, set the minimum length and complexity so they meet or exceed the Part 5.5 requirement for each device, using the lesser value where the device has a maximum. Set a password change interval of at least once every 15 calendar months, either enforced by the device or by a documented procedure with a tracking record. Then configure a limit on unsuccessful authentication attempts or an alert after a threshold, whichever the device supports. The output is the configuration export for each setting and the procedure for the change cycle. The check is a negative test with deliberate failed logins to confirm the lockout or alert fires and reaches the team that monitors it.
Document technical feasibility and exceptions
For every Part that a device cannot meet as written, such as a device that cannot enforce authentication, cannot change a default password or cannot limit failed logins, record the specific limitation, the compensating measures in place, and the review date. Obtain sign-off from the CIP Senior Manager or a documented delegate, and keep the signed exception record with the evidence for the affected asset. Confirm with NERC or your Regional Entity how technical feasibility is evaluated under the version of the standard that applies to you, because the process has changed across recent revisions. The output is a signed exception record per asset, and the check is that every gap found in the earlier steps appears in the register with an owner and a disposition.
Evidence that passes an R5 audit and how to keep it current
An auditor testing CIP-007-6 R5 wants proof that access controls worked throughout the audit period, not only that they were configured once. The four artifacts below map to the main R5 parts, and each needs a routine that keeps it accurate between audits.
Enabled default and generic account inventory
This inventory lists every enabled default or other generic account on each in-scope Cyber Asset, as Part 5.2 requires, with a named owner for each account and the reason it stays enabled. Auditors compare it against a fresh export from the system to find accounts the list misses. Check that disabled accounts are recorded as disabled and that each entry has a current owner. Reconcile it against the live directory and device user lists at a set interval, and file a change ticket whenever an account is created, enabled or removed.
Shared account authorization list
Part 5.3 requires you to identify the individuals authorized to use each shared account, so this list must tie every shared account to named people. Auditors look for a current roster and for evidence that access changed when people changed roles or left. Keep the list in your access management system, not in a spreadsheet only one administrator can edit. Each change to the roster, such as adding an operator or removing a departed engineer, should carry a change ticket that shows approval and the effective date.
Password configuration exports
Exports or dated screenshots of password settings show the minimum length, complexity and the 15-month change interval that Parts 5.5 and 5.6 require for password-only interactive access. Auditors check the setting on the device or directory, not the policy document that describes it. Confirm the export shows the enforced value and the device's maximum where that limits the requirement. Schedule an export after each configuration change and at regular intervals, and store each one with the date and the system that produced it.
Failed-login limits and alert records
Part 5.7 requires either a limit on unsuccessful authentication attempts or an alert after a set threshold, where technically feasible. Keep the configuration export that shows the lockout or alert threshold, plus sample alert records or lockout log entries from the audit period that prove the control fired. Confirm that alerts reach a monitored destination and that someone reviews them. Note any system where the capability is not technically feasible and document the justification for it.
Change tickets and periodic reconciliation
Change tickets link each account creation, default password change, password rotation and removal to an approver and a date, so the evidence shows the state across the audit period. Reconciliation compares the live directory and device configurations against the inventory and the password records, and the result is filed with the reviewer's name. Ask whether your tooling can export audit logs for the full audit period, because a one-time setup record will not satisfy a reviewer asking about changes made months earlier.
How self-hosted open-source tools support R5 evidence
authentik is an identity provider that applications can delegate sign-in to, using OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. Its main relevance to R5 is Part 5.1, which requires methods to enforce authentication of interactive user access where technically feasible. Routing supported applications and management consoles through one identity provider lets the team show which sign-in path each system uses.
- Enforcement point: Applications that delegate sign-in to authentik can show that interactive access passes through the identity provider rather than a local password store.
- Access logs: Sign-in events can serve as evidence of authentication for the sampled periods an assessor selects.
- Protocol coverage: Providers for RADIUS and LDAP may help with network devices and older systems, but each device must be tested.
- Proxy providers: These can front web interfaces that have no native authentication, which needs confirmation against the device's capability.
- Licensing: authentik is released under the MIT license, so the organization should confirm the license terms of the edition and any add-ons it deploys.
Confirm with your own environment whether each in-scope device type can use these protocols, and whether any device needs a local account that authentik cannot cover. Record those exceptions for the Part 5.1 technical feasibility review.
FreeIPA provides single sign-on for Linux and UNIX environments, using an MIT Kerberos key distribution center (KDC) as its authentication core. For R5 it bears most directly on Part 5.1 for Linux and UNIX hosts and on Part 5.2 and Part 5.3, because a central directory makes local accounts and group membership easier to list. Its licensing is GPL-3.0-or-later, which matters for how the organization distributes or modifies it.
- Central account inventory: The directory can export user and service account lists that support the Part 5.2 inventory of generic and default accounts.
- Shared account records: Group membership and ownership attributes can help identify individuals authorized to use shared accounts under Part 5.3.
- Single sign-on logs: Kerberos authentication events can show interactive logins to in-scope hosts.
- Local account limits: Hosts still hold local system accounts, so the inventory must cover them, not only directory entries.
- License review: The GPL-3.0-or-later terms should be reviewed by counsel if the organization modifies the software or ships it to third parties.
Confirm whether each in-scope Linux or UNIX device can join the directory and whether its interactive logins actually pass through Kerberos. Devices that cannot join need their own documented inventory and password controls.
OpenBao stores secrets encrypted in one place, generates dynamic short-lived credentials for systems such as databases, attaches leases that revoke secrets automatically on expiry, and can revoke single secrets or whole trees of credentials. Under R5 it supports Part 5.4 on changing default passwords and Part 5.5 and Part 5.6 on password strength and change intervals, where a device accepts credentials issued by the vault. It is released under the MPL-2.0 license.
- Rotation records: Lease and revocation logs can document when a credential was issued, changed or expired.
- Dynamic credentials: Short-lived credentials can reduce reliance on long-lived shared passwords, although they do not remove every generic account.
- Bulk revocation: Revoking a credential tree gives a documented path for removing access during an incident or staff change.
- Integration limits: Many embedded and operational devices cannot consume dynamic credentials, so the vault covers only the systems that integrate.
- License review: MPL-2.0 is a file-level copyleft license, so the organization should review obligations if it modifies OpenBao source files.
Confirm which in-scope devices can accept credentials from the vault, and how the password change for each remaining device is performed, recorded and tested against the 15-month limit.
GitLab Community Edition includes pipeline secret detection, which scans files committed and pushed to the repository in a CI/CD job and writes detected secrets to a gl-secret-detection-report.json job artifact in every tier. This does not enforce R5 directly, since it does not control logins. Its evidence value lies in showing that hardcoded passwords or keys in automation code are found before they reach production, which supports the organization's default and shared credential handling. The license is MIT.
- Scan job evidence: The pipeline job log and the JSON artifact can show that scanning ran on the stated commits.
- Finding records: Detected secrets listed in the artifact can be tracked to remediation tickets.
- Coverage limits: The scan covers committed and pushed files, so credentials typed into device consoles or kept outside the repository are out of view.
- Retention: Artifacts expire according to the pipeline settings, so the organization must set retention to match its evidence period.
- Edition check: Confirm the features your edition provides before relying on them, since this tab's capability is described for the Community Edition in the supplied fact.
Confirm that automation repositories touching in-scope systems are included in the pipeline, and that exposed credentials trigger a rotation under the same procedure as Part 5.4.
What meeting R5 costs in money and effort
This table compares the cost components of meeting CIP-007-6 R5, who is paid for each one, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for requesting a fixed-scope written quote, since no price is published here.
| Cost component | One-time or recurring | What drives the cost up | How to keep it down |
|---|---|---|---|
| Identity and access tooling or licenses | Recurring license or subscription where commercial, plus one-time setup | Number of users and integrated systems, commercial directory or MFA licensing, and support tiers | Use open-source identity providers such as authentik or FreeIPA to remove license spend, then confirm the staff or partner time to run them |
| Engineering time for identity integration | One-time, with periodic rework after upgrades | Number of applications and Cyber Assets that must delegate sign-in, and whether firmware supports central authentication | Prioritize high impact and medium impact BES Cyber Systems, and document which devices use local accounts as an exception |
| Device configuration for R5 settings | One-time per device, recurring when devices are replaced or re-imaged | Count of devices and sites, vendor-specific default password procedures, and devices that cannot enforce length or complexity | Standardize configuration baselines so each device type is configured once and checked against a template |
| Shared and generic account inventory upkeep | Recurring, tied to staffing changes and reviews | Number of shared accounts, generic service accounts and staff turnover | Eliminate shared accounts where possible, and assign each remaining account a named owner in a single register |
| Password change and failed-login tracking | Recurring, at least every 15 calendar months where password-only access applies | Number of password-only devices and manual change procedures | Enforce changes centrally where the platform allows it, and route failed-login alerts to existing monitoring |
| Evidence collection for each audit period | Recurring for every audit period | Manual screenshots, number of sites, and missing logs or change records | Keep configuration exports, account registers and alert records in a fixed location with a repeatable collection checklist |
| External testing or independent review | Recurring, scoped by the entity and its assessor | Scope of systems reviewed and depth of testing of authentication and default credentials | Define test scope in writing before work begins, and confirm whether a retainer or one-time engagement fits the plan |
| Auditor sampling time | Recurring at each Compliance Audit or Spot Check | Quality of evidence, number of devices sampled, and gaps found during sampling | Prepare sample-ready evidence packages so auditors spend less time searching for records |
Who does what for R5: your team, a partner and the auditor
Your organization owns the R5 controls. The registered entity is the party the Compliance Enforcement Authority monitors, so the obligation to enforce authentication, inventory generic and shared accounts, change known default passwords and limit failed logins stays with you, whatever tools or partners you use. Your team also decides how the requirement applies to each Applicable System and approves any exceptions that carry risk.
- Control ownership: Name an accountable owner for interactive authentication, shared account handling and password settings on each in-scope Cyber Asset.
- Exception approval: Document who may approve a technical feasibility position or an alternative method, and keep the approval record with the reasoning.
- Inventory maintenance: Keep the list of enabled default and generic accounts and the individuals authorized to use shared accounts current as systems change.
- Password and lockout decisions: Decide which password policy and failed-login response apply where a device cannot meet the requirement as written, then confirm the setting on the device.
- Evidence review: Read the evidence before an audit, so you can explain each control in your own words.
Before relying on any partner output, confirm that your own staff can run the inventory and explain the settings without outside help.
An implementation partner such as DeployOpen can prepare the systems and evidence that support R5. Under a written scope agreed before work starts, a partner can plan and integrate identity services, build configuration baselines, set up inventory tooling and assemble evidence packs for your team to review. The partner works inside your environment, but the decisions and the compliance position remain yours. DeployOpen does not issue audit reports, attestations or certifications.
- Identity integration: Prepare how interactive logins to in-scope systems are authenticated through a central identity service, where your design allows it.
- Configuration baselines: Document hardened settings for password length, complexity, expiry and failed-login handling, with the device limits that apply.
- Inventory tooling: Build scripts or reports that list accounts and their status, so the inventory can be refreshed on a schedule.
- Evidence packs: Organize configuration exports, change records and test results against each sub-requirement for your review.
- Written scope: Agree deliverables, exclusions and handover in writing, including who keeps the credentials and runbooks afterwards.
Ask the partner which outputs are settings and reports, and which are judgments that your team must still sign off.
The independent auditor or the Regional Entity tests whether R5 is met and records findings. Under the NERC compliance monitoring program, the Compliance Enforcement Authority reviews your evidence through audits, spot checks, self-certifications and self-reports. The auditor selects samples, examines configurations and records, and states whether the requirement was met. An auditor is not part of your compliance team and cannot design or build the controls it tests.
- Sampling: The auditor chooses accounts, devices and time periods to examine, which may differ from the list you prepared.
- Testing: Expect review of authentication settings, the default and generic account inventory, password change records and failed-login alerts.
- Findings: Violations are documented in findings, which can lead to a mitigation plan or enforcement action.
- Independence line: The partner who helped build a control should not be the party who judges it, and vendor staff cannot serve as the auditor for the same engagement.
- Evidence retention: Keep records for the audit period, so the auditor can test the period in question.
Confirm with your Regional Entity which evidence it expects and how it wants it submitted before the engagement begins.
Where R5 programs usually fall short and how to close the gap
Most CIP-007-6 R5 findings come from gaps between what a program says and what the devices actually do. The cards below pair each common gap with the closure step and the evidence an auditor will ask to see, so the account inventory, password settings and feasibility decisions can be shown for each Applicable System.
Shared accounts without named individuals
Shared accounts are often used for maintenance, vendor access or emergency logins, yet no list ties each account to the people authorized to use it. Part 5.3 expects you to identify the individuals with authorized access to each shared account. Close the gap by recording each shared account against a named roster, with the approver and the date the roster was last reviewed. Evidence is the roster itself, matched to the account list and to access records showing who actually signed in.
Default passwords left after commissioning
Vendor default credentials often survive commissioning on appliances, consoles and network gear because the installer tested the device and moved on. Part 5.4 requires changing known default passwords to the extent each Cyber Asset supports. Close the gap with a commissioning checklist that requires a default-credential check and a signed record before a device enters service. Evidence is the completed checklist, plus a sample of devices showing the changed credential status.
Generic accounts hidden on embedded devices
Network switches, protective relays, meters and other embedded devices often ship with generic or service accounts that never appear in the central directory, so the Part 5.2 inventory misses them. Close the gap by pulling account lists directly from each device type during the inventory cycle, not only from the identity provider. Evidence is the device-level account export, the enabled or disabled status of each generic account, and the reconciliation to the inventory.
Password settings not evidenced per device
A policy document stating a minimum length and complexity does not show that each password-only device enforces it. Part 5.5 applies the lesser of eight characters or the device maximum, and three character types or the device maximum. Close the gap by recording the actual setting for each device model, including any device limit, and by testing a sample. Evidence is the per-device configuration output or screenshot, dated and tied to the asset record.
Technical feasibility left undocumented
Where a device cannot enforce authentication, password changes, or failed-login limits, the program needs a documented reason and a compensating approach. Parts 5.1, 5.6 and 5.7 each use the phrase where technically feasible, so the reason has to be written down. Close the gap by recording, for each exception, the vendor limitation, the date it was assessed, and the procedural control applied. Evidence is the signed feasibility record and the vendor documentation or test result that supports it.
Failed-login alerts never reviewed
Thresholds for failed login attempts are often configured on the device or in a central tool, but nobody reviews the alerts or acts on them. Part 5.7 asks for either a limit on unsuccessful attempts or an alert after a threshold, and the alert has to reach a person or process that responds. Close the gap by routing alerts to a named queue, setting a review cadence, and documenting the response. Evidence is the alert configuration, the alert log, and the record of follow-up for each triggered alert.
Questions buyers ask about meeting R5 and hiring help
How much effort does CIP-007-6 R5 take compared with the other CIP-007 parts?
R5 is usually one of the more involved parts of CIP-007-6 because it touches every interactive login path, not just one network or software layer. Part 5.2 and 5.3 require a complete inventory of generic and shared accounts, which often takes longer than expected when accounts sit on field devices, legacy consoles and vendor appliances. Parts 5.4 through 5.7 then need a decision per Cyber Asset, and several depend on what the device can technically do. Effort tends to scale with the number of asset types and the number of accounts, not with the number of pages in the standard. Ask a potential partner to break its quote down by inventory, configuration, technical feasibility documentation and evidence collection.
Can a small entity meet R5 in-house without outside help?
Yes, a small entity can meet R5 in-house if it has staff who understand the in-scope Cyber Assets, can read the applicable table in CIP-007-6, and can keep evidence current. The usual gaps are not technical but procedural: no one owns the account inventory, shared credentials live in spreadsheets, and password change records are not kept. Outside help is most useful for the inventory, for designing an identity and secrets setup that fits the entity's devices, and for a readiness review before a Regional Entity audit. Whatever the decision, the entity remains responsible for its compliance program. Ask any partner to state which tasks it will perform and which remain with the entity's staff.
What does a partner need from the entity to start an R5 engagement?
A partner needs enough information to scope the work before it touches any system. The entity should provide its CIP-002 categorization of BES Cyber Systems, the list of in-scope Cyber Assets with their vendors and firmware, the current account listings from each system, and the existing password and access procedures. Access to the directories and identity sources that control interactive login is also needed, along with named contacts from operations, IT and compliance. Ask the partner to confirm in writing which of these inputs it needs before a fixed-scope quote is issued, and which it expects to receive during the engagement.
How long does R5 preparation usually take, and what drives that?
No supplied fact gives a standard duration for R5 preparation, so the honest answer depends on the environment. The main drivers are the number of in-scope systems, how many generic and shared accounts exist, whether devices support central authentication, and how many devices need a documented technical feasibility position where a control cannot be applied. Vendor coordination for firmware or default password changes can also set the pace. Ask for a timeline in the written scope that lists the phases, the entity's dependencies, and the points where operations must approve a change to a live system.
Can open-source identity and secrets tools satisfy R5 by themselves?
No single tool satisfies R5. Identity providers such as authentik and FreeIPA can delegate sign-in and enforce central authentication for applications and Linux and UNIX hosts, which supports Part 5.1 where the device supports it. OpenBao can generate short-lived credentials and revoke them, which helps with shared and generic secrets. But R5 also requires an inventory of generic and shared accounts, default password changes on devices that cannot use central authentication, password length and complexity settings, and the 15-month change and failed-login controls. Those depend on the entity's process and on device capability, so the tools are one part of the evidence set. Confirm with each vendor which features apply to your devices before you rely on them.
What will the auditor sample when testing R5?
An auditor typically tests R5 by selecting in-scope Cyber Assets and checking whether the controls work as the entity describes them. Expect requests for the current account inventory, the list of individuals authorized for each shared account, records showing default passwords were changed or documented as not changeable, and configuration screenshots or exports that show password length, complexity and failed-login settings. Evidence of password changes at intervals of no more than 15 calendar months for password-only interactive access is also commonly requested. The auditor's sample depends on the audit scope set by the Regional Entity, so the entity should keep records that can be pulled quickly for any in-scope device.
Can R5 work be bought as a fixed-scope engagement?
Yes, DeployOpen's implementation work is generally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For R5, a fixed scope would normally name the systems covered, the account inventory method, the identity and secrets components to be implemented, the evidence to be produced, and what the entity must provide. Recurring activities such as periodic password reviews, upgrades or continuous testing can be handled under a separate retainer. DeployOpen prepares systems and evidence but does not issue audit reports or determinations; the Compliance Enforcement Authority makes those. Ask for the scope, deliverables, exclusions and entity responsibilities in writing before comparing quotes.
What should a written R5 quote include?
A useful quote lists each R5 part separately and states what will be delivered for it. Ask for the in-scope asset list, the account inventory method and who signs off on it, the approach for devices that cannot use central authentication, and the process for default password changes. The quote should also state the evidence package, the review points with the entity, and what happens if a device lacks the capability needed for a requirement. Finally, it should name which costs are one-time, such as design and implementation, and which recur, such as periodic review, retainer support or licensing for any commercial component.
How DeployOpen scopes and prepares R5 evidence
DeployOpen works on CIP-007-6 R5 as an implementation partner. We prepare the systems, access configurations and evidence that a registered entity owns and presents to its Compliance Enforcement Authority, while the entity keeps accountability for its controls.
How we scope
- Confirm which BES Cyber Systems, EACMS, PACS and PCAs fall under the Applicable Systems column for R5.
- Inventory enabled default and generic accounts and shared account holders on each in-scope asset.
- Record in the written scope which interactive access methods, identity sources and password-only systems are covered.
How we build
- Configure central sign-in for applications through an identity provider where the asset supports it.
- Set up short-lived credentials and secret storage for system accounts, so static shared passwords are reduced.
- Document where password length, complexity, 15-month change and failed-login limits are enforced, or where a documented alert or technical limit applies.
How we hand over
- Deliver a written record of each R5 part, the systems it applies to and the configuration that enforces it.
- Provide account inventories, default password change records and shared account lists in a format your team can keep current.
- Show the evidence an auditor would ask for, such as configuration exports and login failure alert logs, and confirm retention with your compliance lead.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- DeployOpen does not issue audit reports or certifications. Independent auditors and the Regional Entity assess compliance.
