What must an Intermediate System do to meet CIP-005 remote access?
CIP-005-7 R2 Part 2.1 requires that all Interactive Remote Access to a high impact or medium impact (with External Routable Connectivity) BES Cyber System route through an Intermediate System, so the initiating device never reaches the applicable Cyber Asset directly. Part 2.2 requires the encryption protecting those sessions to terminate at the Intermediate System, and Part 2.3 requires multi-factor authentication on every Interactive Remote Access session. For a registered entity whose staff or vendors log into a control environment from outside, the proxy is the single point where those three obligations are met, so its design decides most of the audit story. Read the standard itself in the CIP-005-7 standard PDF before scoping, because the Applicable Systems table defines exactly which assets and access paths are in scope.
The cost and effort of meeting these parts depend on the scope of the work, not on a fixed package. The main drivers are the number of access paths (staff consoles, vendor jump hosts, engineering workstations, and any system-to-system links that might be treated differently), how much the entity already runs on an identity provider that can enforce MFA, and how much session evidence it already keeps. An entity that has to add MFA, build recording and set up logging from scratch will spend more than one that extends existing identity and log infrastructure. Ask any implementation partner for a written scope that lists each access path, each identity source, the recording and retention design, and who performs the cut-over testing. Expect one-time costs for design, build and testing, and recurring costs for licenses, patching, log storage and periodic evidence pulls.
Ownership is split, and the split matters for the evidence file. The registered entity owns the control and is accountable for it to its Regional Entity. An implementation partner, such as DeployOpen, can prepare the Intermediate System, configure encryption termination and MFA, set up session logging, and document how each part is met, but it does not decide compliance. Only the Regional Entity audit team judges whether the entity complies, based on evidence the entity produces and can defend. Confirm with your Regional Entity which evidence formats it accepts before the build starts, and confirm the license and edition terms of any open-source proxy with its vendor, since those terms can rule the tool in or out for a given organization.
Which proxy capabilities map to each CIP-005 need
CIP-005-7 Part 2 asks for Interactive Remote Access through an Intermediate System, encryption that ends there, multi-factor authentication, and vendor session controls. The cards below pair each capability an access proxy may provide with the evidence it creates and what the entity must still verify in its own environment.
Encryption termination at the Intermediate System
The encrypted session must end at the Intermediate System, not at the BES Cyber System, to satisfy Part 2.2. Confirm the TLS or SSH termination point in your architecture diagram, and check that no direct path exists from the initiating Cyber Asset to the applicable Cyber Asset. Capture the configuration and a network test showing the session terminates at the proxy. Confirm the cryptographic settings your own policy requires, because the proxy's defaults may not match them.
Per-session multi-factor authentication
Part 2.3 requires multi-factor authentication for every Interactive Remote Access session, so the check must happen on each session, not only at login to the proxy. Teleport Community Edition includes per-session MFA, which can produce authentication records you can export. Confirm which factors your identity provider accepts, whether shared or service accounts can bypass the prompt, and how you will show that MFA applied to each vendor session.
Vendor session visibility and termination
Parts 2.4 and 2.5 require methods to see active vendor remote access and to disable it. The proxy's session list and admin termination action can serve as those methods, but they cover only sessions routed through the proxy. Confirm that system-to-system vendor access is also covered by a separate method, and test that terminating a live session drops the connection and logs the action.
Session recording and playback
Session recording gives the entity a reviewable record of what a vendor did during Interactive Remote Access. Teleport records SSH and Kubernetes sessions by capturing full terminal output, and it can record desktop screen and mouse input and database queries. Confirm which protocols your vendors use are covered, where recordings are stored, and how long your retention policy keeps them.
SIEM export of audit events
Structured audit events from the proxy, exported to a SIEM, give the entity a central log of logins, MFA results, session starts and terminations. Teleport Community Edition supports export of its structured audit logs to a SIEM. Confirm the export pipeline keeps timestamps synchronized, that alerts fire on failed MFA or unexpected access, and that the log retention in the SIEM meets your evidence period.
Identity integration and access governance
Connecting the proxy to your identity provider determines who can reach an applicable system and how that access is reviewed. Single sign-on with OIDC or SAML, access lists, and access reviews are Teleport Enterprise features, while Community Edition supports GitHub SSO only. Confirm which identity source your vendor accounts come from, who approves access, and whether your review process can be shown without a paid edition.
Teleport Community Edition versus Enterprise for CIP work
Community Edition covers several of the controls CIP-005 R2 asks an Intermediate System to support. Per-session multi-factor authentication addresses Part 2.3 for each Interactive Remote Access session, and session recording with playback gives you a record of what a vendor did once connected. Structured audit logs can be exported to a SIEM, which lets you retain access records outside the access proxy itself. These capabilities are the starting point for evidence, but they do not replace your own procedures for determining and disabling vendor sessions.
- Per-session MFA: Each Interactive Remote Access session can require a second factor, which you should test against your own Part 2.3 design.
- Session recording with playback: SSH and Kubernetes sessions are captured with terminal output, so reviewers can replay activity.
- Structured audit logs: Events can be exported to a SIEM for retention and correlation with your other CIP evidence.
- GitHub SSO only: Community Edition does not offer OIDC or SAML single sign-on, so identity integration with your directory needs review.
- CLI-only access requests: Access requests are handled through the command line, which affects how you document approvals.
Before relying on these features, confirm the exact feature set for your version against the vendor's feature matrix and test session recording in your own environment.
Several capabilities that many CIP programs expect are not in Community Edition. Single sign-on with OIDC or SAML, access lists with access reviews, device trust, and session moderation are listed as Enterprise features. Each one maps to a practical need: identity from your existing directory, periodic review of who holds access, restricting sessions to managed devices, and having a second person watch or approve a live vendor session. Whether you need them depends on how your vendor access process is designed and what your auditors will test.
- OIDC or SAML single sign-on: Connects vendor and staff logins to your identity provider.
- Access lists and access reviews: Supports periodic review of who can reach which BES Cyber Systems.
- Device trust: Limits sessions to devices that meet your posture requirements.
- Session moderation: Lets an approver observe or control a live session.
- Identity governance: Adds lifecycle tooling for accounts and entitlements.
Ask the vendor to confirm which Enterprise features are included in your quoted edition and whether they are available in your deployment model.
The licence determines which binaries you can legally use. Teleport moved its source code from Apache-2.0 to AGPL-3.0-or-later with version 15, and only the API module remains Apache-2.0. The prebuilt Community Edition binaries are distributed under the Teleport Community Edition License, a modified Apache 2.0 licence that permits use only by organizations with fewer than 100 employees and less than US$10 million in annual revenue. Larger organizations have two routes: build Community Edition from source under AGPL-3.0-or-later, or purchase Enterprise.
- Source licence: AGPL-3.0-or-later applies to the source code from version 15 onward.
- Prebuilt binary limit: The Community Edition License restricts use to organizations under 100 employees and under US$10 million annual revenue.
- Build from source: Larger organizations can compile under AGPL, which carries its own obligations if you modify and provide the software over a network.
- Enterprise purchase: A commercial licence covers the Enterprise feature set and its terms.
- Counsel review: Your legal team should review how the AGPL applies to your deployment and any modifications.
Confirm licensing with the vendor and your counsel before deployment, and document the decision in your CIP-005 evidence.
Choosing between editions is a decision about organization size, the controls you must evidence, and the cost of building and maintaining a source build. An organization that is below the Community Edition License thresholds and whose needs fit the Community feature set has a simpler path. A larger organization that needs SSO, access reviews or session moderation will likely look at Enterprise first, while still weighing the option of a source build if its feature needs are narrower. The right answer comes from your written requirements, not from the feature list alone.
- Size thresholds: Check current employee count and annual revenue against the licence limits, including affiliates if your counsel advises it.
- Required controls: List which Part 2.3, 2.4 and 2.5 behaviors need features beyond Community Edition.
- Identity integration: Confirm whether GitHub SSO is acceptable or whether directory integration is required.
- Build and maintenance: A source build shifts patching, testing and support responsibility to your team or an implementation partner.
- Vendor support: Ask what support and update commitments come with each option.
Record the edition decision, its licence basis and its review date so an auditor can see why the chosen option meets your requirements.
How an Intermediate System gets implemented and evidenced
The sequence moves from confirming which BES Cyber Systems are in scope to a tested, documented access path that an auditor can trace from policy to session record. Each step produces an artifact the entity owns, and the entity remains responsible for every control it relies on.
Confirm applicable systems from the CIP-002 categorization
The entity's CIP Senior Manager or delegate reviews the CIP-002 categorization to identify which high impact BES Cyber Systems and medium impact BES Cyber Systems with External Routable Connectivity, along with their associated Protected Cyber Assets, can be reached remotely. Vendors and internal staff who open Interactive Remote Access sessions into those systems are listed by name and role. The output is a scoped inventory of in-scope systems and the access paths that reach them. Done means every path has a named owner and a matching CIP-002 classification.
Document current remote access paths
The entity's network and operations teams map every existing route into the in-scope systems, including VPN tunnels, jump hosts, direct SSH or RDP sessions, vendor support tools and system-to-system connections. Each route is recorded with its source, destination, protocol, authentication method and the people or accounts that use it. Gaps such as shared accounts or direct initiating-device access are flagged for remediation. Done means the team holds a current diagram and table that an assessor can compare against the final design.
Select and architect the proxy
The entity, with its implementation partner if one is engaged, chooses the Intermediate System and designs where it sits in the network so that the initiating Cyber Asset never reaches an applicable Cyber Asset directly. The design records how TLS or other encryption terminates at the Intermediate System, how multi-factor authentication integrates with the identity source, and which edition of the chosen open-source proxy provides the needed features. Confirm the license terms and edition limits in writing before selection, because community builds can restrict use by organization size. Done means an approved architecture document and a documented license decision.
Deploy the Intermediate System inside the entity environment
Engineers install and harden the Intermediate System within the entity's own data centers, cloud accounts or networks, applying the entity's baseline configuration and change control process. Access policies are written so that only the approved users and vendors can reach the in-scope systems through the proxy. Session audit logs and recording storage are placed on infrastructure the entity controls, with retention set to match its evidence needs. Done means a change record, a tested configuration baseline and a working path from the proxy to a test target.
Configure MFA and session recording
Engineers enable multi-factor authentication for every Interactive Remote Access user path, then test each path with an unprivileged account to confirm that a session cannot be established without the second factor. Session recording is switched on for all proxied sessions, and playback is tested with a sample session to confirm that commands and outputs are captured. Audit events are forwarded to the entity's log management or SIEM platform. Done means dated test results showing MFA enforcement, a retrievable recording and a log entry for each test session.
Test disabling of vendor access
The entity runs a documented test that identifies an active vendor remote access session through the monitoring method it has chosen, then disables that session using the disablement method it has chosen. The test is repeated for system-to-system remote access where that path exists. Results are compared with the expected outcome, and any failed step is recorded with a corrective action. Done means a signed test record that shows the session was detected, terminated and confirmed closed, with the operator and date named.
Collect and retain the evidence set
The entity assembles the artifacts that show the control operated: the scoped inventory, the architecture and license decision, change records, MFA and recording test results, sample session recordings, access list exports, and vendor disablement test records. Each item is labeled with the CIP requirement it supports and stored under the entity's CIP evidence retention rules, including protections for BES Cyber System Information. Done means a retrievable index that maps each artifact to its requirement and owner.
Hand over for the independent audit
The entity walks through the evidence set internally, confirms that every access path in the inventory uses the Intermediate System, and corrects any gaps before the Regional Entity or its auditor reviews the program. An implementation partner, where engaged, hands over runbooks, configuration records and test scripts so the entity can operate and re-test the control. The auditor, not the partner, decides whether the evidence meets the standard. Done means a handover package accepted by the entity's CIP Senior Manager and a list of open items with owners.
Who is paid for what when meeting CIP-005 remote access
This table shows who is paid for each part of meeting the CIP-005 Interactive Remote Access requirements through an Intermediate System, whether each cost is one-time or recurring, and what drives it up. Read it as a checklist for quotes: ask each provider which rows its figure covers, and confirm the rest with your own team and auditor. No amounts are shown because cost depends on your environment and written scope.
| Cost component | Who is paid | One-time or recurring | What drives the cost |
|---|---|---|---|
| Internal staff | Your own engineers, operations staff and CIP compliance team | Both: initial design and recurring review | Number of vendors and session types, how often access rules change, and the depth of review your CIP Senior Manager requires |
| Implementation partner | An outside firm such as DeployOpen, paid under a written fixed-scope agreement | Mostly one-time for build, hardening and documentation; recurring if you buy support or upgrades | Number of Intermediate Systems, number of BES Cyber Systems in scope, integration with existing access tools, and evidence deliverables agreed in scope |
| Proxy software or licensing | The software vendor, or none if you build an open-source edition yourself | Recurring if you buy a commercial edition or support; one-time effort to build from source | Organization size and revenue against the Teleport Community Edition License limits, and whether you need Enterprise features such as OIDC or SAML single sign-on |
| Infrastructure hosting | Your cloud provider, data center operator or hardware vendor | Recurring, plus one-time setup for high availability and network segmentation | Instance count, storage for session recordings, redundancy design, and whether the system sits inside the Electronic Security Perimeter |
| Identity provider and MFA | Your identity provider vendor, or an existing internal directory you already run | Often recurring per user or per license, plus one-time integration | Number of named vendor and staff users, the MFA methods you accept, and whether your identity provider already supports the proxy |
| SIEM integration | Your SIEM vendor, plus the team or partner that configures the log export | One-time for parsing and alerts; recurring for log storage and retention | Volume of audit events, retention period set by your CIP evidence plan, and the number of alerts you tune to vendor session activity |
| Independent audit | The Regional Entity or NERC for compliance monitoring, and any third-party assessor you hire for a readiness review | Recurring on the audit cycle set by the Regional Entity; readiness review is one-time | Your registration category, the risk-based schedule, and the size of the evidence package. The Regional Entity audit is not a DeployOpen deliverable. |
Common questions about CIP-005 Intermediate Systems
Is an open-source access proxy enough for CIP-005 Intermediate Systems?
An open-source proxy can serve as the Intermediate System, but it has to meet every part of CIP-005-7 R2 in your environment, not just route traffic. The proxy must stop the initiating Cyber Asset from reaching the applicable Cyber Asset directly (Part 2.1), terminate encryption at the Intermediate System (Part 2.2), enforce multi-factor authentication for every session (Part 2.3), and give you methods to see and disable active vendor sessions (Parts 2.4 and 2.5). Each of those needs configuration, integration with your identity provider and logs that feed your evidence set. Before choosing, check which of those functions the edition you intend to run includes, because some identity and governance features are limited in the free tier. Your CIP Senior Manager should also confirm the design with your Regional Entity's expectations.
How do Community Edition license limits affect a utility?
The license limits can decide the question before any technical work starts. Teleport's prebuilt Community Edition binaries ship under a license that allows use only by organizations with fewer than 100 employees and less than US$10 million in annual revenue. Most utilities exceed those thresholds, so a larger organization would need to build from source under the AGPL-3.0-or-later terms or buy an Enterprise edition. Building from source moves responsibility for patching, build integrity and support onto your staff or your partner. Enterprise features such as single sign-on with OIDC or SAML, access lists, access reviews and session moderation are not in Community Edition. Confirm licensing with your legal team and the vendor before design, because the choice changes both cost and who maintains the platform.
Can a vendor keep using its own remote access tool?
A vendor can keep its own tool only if every one of its sessions still meets CIP-005-7 R2. The vendor's tool cannot create a direct path from the vendor's laptop to a BES Cyber System, because Part 2.1 requires all Interactive Remote Access to pass through an Intermediate System. Encryption must end at that Intermediate System, MFA must apply to each session, and you must still be able to see active vendor sessions and disable them under Parts 2.4 and 2.5. In practice, many entities route vendor sessions through the same controlled entry point as their own staff. Put this requirement in vendor contracts and check it during onboarding, and confirm with your compliance team whether any vendor system-to-system access also needs to be covered.
What does the work need from our own staff?
Your staff keeps ownership of the controls, so they must make the decisions and be able to show the results. Operations and IT staff need to define which Cyber Assets are in scope, approve the access design, decide who may initiate remote sessions, and maintain the identity provider and MFA settings. Someone must review session logs and recordings, respond when a vendor session needs to be terminated, and keep the access list current as people change roles. Your compliance lead should map each sub-part of CIP-005-7 R2 to a named configuration and a named evidence item. An implementation partner can build and document the system, but it cannot make those ownership decisions or sign off on compliance on your behalf.
How long does setup take for a proxy like this?
Setup time depends mainly on scope, and the duration should come from a written scope rather than a general rule. The number of Electronic Access Points involved, how many vendor and staff access paths exist, whether single sign-on is available or must be built, the number of Cyber Assets in each applicable system, and the amount of documentation and testing your Regional Entity expects all change the effort. Environments with a few well-understood access paths take far less time than sites with many legacy vendor tools. Ask any partner for a phased plan that separates design, build, testing, cutover and evidence collection, and ask what each phase depends on from your side, such as change windows and approvals.
Can a partner issue a CIP compliance certificate for our proxy?
No. There is no CIP certificate, and no implementation partner can issue one. NERC and the Regional Entity, which acts as the Compliance Enforcement Authority, monitor compliance through audits, spot checks, self-certifications, self-reports and other processes. A partner can design and build the Intermediate System, configure encryption and MFA, document the procedures, and prepare the logs and recordings that show the controls work. The registered entity owns the controls and answers for them in any audit. When you engage a partner, ask for written deliverables that map to CIP-005-7 R2 Parts 2.1 to 2.5 and for an agreed list of evidence artifacts, and treat the outcome of any audit as the Compliance Enforcement Authority's determination.
Where Intermediate System projects stall
Most Intermediate System projects stall on scope, not on the proxy itself. The first common gap is unmapped vendor paths: vendors often reach a BES Cyber System through a jump host, a VPN concentrator, a managed service portal or a support tool that nobody has written down. Each of those paths is an Interactive Remote Access route that must pass through the Intermediate System under Part 2.1, so the inventory of vendor access has to be built from firewall rules, account records and vendor contracts, not from the list of tools the team already approved. Confirm, with the people who run the networks and with each vendor, that every inbound path to an applicable Cyber Asset has been traced to a documented owner.
The second gap is system-to-system access, which teams often treat as outside the project because it is not a person at a keyboard. Part 2.4 covers active vendor remote access including system-to-system access, and Part 2.5 requires a method to disable it. Service accounts used by vendor monitoring agents, file transfer jobs and remote diagnostics are the usual blind spot, and the same gap appears in multi-factor authentication when service accounts sit outside the MFA flow used for people. Ask who owns each non-interactive account, whether its sessions can be listed and terminated, and how that is shown in the evidence.
Recording and licensing decisions cause the last set of delays. Session recordings that no one has assigned a retention period, storage location or access rule become an evidence problem later, and the recordings themselves can contain BES Cyber System Information that CIP-011 controls. On the licensing side, Teleport's Community Edition terms limit use to organizations under 100 employees and under US$10 million in annual revenue, and its SSO, access reviews and session moderation are Enterprise features. Confirm your organization's size against those terms, check which features your design depends on in the current feature matrix, and get the edition decision approved before the architecture is built.
How DeployOpen scopes and prepares CIP-005 remote access
DeployOpen plans, implements and documents self-hosted open-source access platforms inside your own infrastructure, including the Intermediate System that CIP-005-7 requires for Interactive Remote Access. The organization keeps ownership of its controls, while DeployOpen prepares the systems, configuration and evidence that an independent auditor will review.
How we scope
- Confirm which BES Cyber Systems and Protected Cyber Assets in scope need Interactive Remote Access through an Intermediate System.
- Record the written scope, deliverables and timeline before any work starts, since engagements are fixed-scope.
- Confirm the license and edition fit for your organization size and revenue before selecting an access proxy platform.
How we build
- Deploy the Intermediate System inside your network so the initiating Cyber Asset never reaches an applicable Cyber Asset directly.
- Configure encryption that terminates at the Intermediate System and multi-factor authentication for every Interactive Remote Access session.
- Enable session recording, structured audit logs and export to your SIEM, then test that each control produces the expected record.
How we hand over
- Document the configuration, access procedures and the methods used to determine and disable active vendor remote access sessions.
- Provide an evidence map linking each CIP-005-7 Part to the configuration, log samples and test results that show it operating.
- Train your staff to run, review and terminate sessions so the controls keep working after the engagement closes.
How we support
- Offer ongoing support, upgrades and continuous testing of the Intermediate System as a retainer, agreed in writing.
- Review changes to the access platform, including version upgrades, against the Intermediate System controls before they reach production.
- Ask your compliance lead to confirm the evidence retention and audit period with your Regional Entity, since DeployOpen does not issue audit reports.
