Manav.id
Vertical · 5 min read

CIP-003-9 landed on small utilities in April 2026. Nobody sells the evidence part.

CIP-003-9 landed on small utilities in April 2026. Nobody sells the evidence part.

The compliance date passed quietly for most of the industry and loudly for the entities it actually landed on. From 1 April 2026, registered entities with low-impact BES Cyber Systems must determine vendor remote access sessions and be able to disable them. The vendors who sell into that requirement all solve the same half of it.

What does CIP-003-9 require that nobody sells?

Evidence of who authorised a vendor session. From 1 April 2026 vendor electronic remote access controls extended to low-impact BES Cyber Systems — the tier run by co-ops and municipals with the smallest compliance staffs. Every tool on the market controls the connection; none records who permitted it.

Key takeaways
  • CIP-003-9 requires the capability to determine and disable vendor remote access. It does not require evidence of who authorised a given session, and no product supplies it.
  • A connection log answers was there a session. A regional entity auditor asks who approved this one, for what work, until when.
  • Low-impact entities can close this without a privileged access management deployment, which is the assumption most guidance quietly makes.

The morning after the compliance date

What tools provideSession brokeringRecording and playbackTime-boxed accessConnection logsWhat the evidence needsWhich named entity person permitted itFor which system and scopeWhen, and for how longTestable months latervs

A compliance engineer at a distribution cooperative described the position plainly: three substations with low-impact assets, one person covering NERC compliance alongside two other jobs, and a new obligation whose commercial answer starts at a six-figure platform.

She had the connection side handled. Firewall rules restricting vendor source addresses. A jump host with session recording. A documented procedure for enabling and disabling access. What she did not have — and could not buy — was an answer to the question her regional entity asked at the next engagement: for the vendor session on 14 May, who authorised it, for what work, and how long was it meant to last?

The answer was in an email thread. It was a perfectly honest answer and an unverifiable one.

What the standards actually require

Precision matters here because vendors are imprecise about it in marketing.

StandardRequirement, in substanceWhat it does not require
CIP-005-7 R2.2Multi-factor authentication for all interactive remote access sessionsThat the authorisation to hold the session is recorded or attributable
CIP-005 vendor provisionsMethods to determine active vendor-initiated remote connections and to disable themEvidence of who inside the entity permitted the connection
CIP-003-9 (from 1 Apr 2026)Vendor electronic remote access controls extended to low-impact BES Cyber SystemsA prescribed evidence format
CIP-005-8 draftingA dedicated Vendor Remote Access requirements table(In development at time of writing)

Read the right column. Every obligation concerns capability — can you see it, can you cut it. Authorisation is assumed to be handled by the entity's own processes, and entity processes are email, tickets and phone calls.

Why the market solved the other half

This is not a criticism of the tooling. Secure remote access appliances, MFA products and OT monitoring platforms all address genuine requirement language, and they do it well. The reason none of them produces authorisation evidence is that nothing in the standards asks for it, and products are built against requirement text.

The consequence is a market where every ranking result for a CIP-003-9 search sells connection control, and an entity looking for the other half finds nothing.

Session recording tells you what happened inside the session. It cannot tell you whether the session should have existed.

The Vendor Session Authorization Receipt

A small artefact, deliberately. Low-impact entities cannot absorb a platform, so the design constraint is that it must work with a jump host and a browser.

  1. The vendor requests access naming the asset, the work order and the intended change scope.
  2. A named entity approver signs a delegation: assets in scope, permitted activities, expiry in hours.
  3. The vendor engineer signs an assertion against that delegation at session start. The jump host checks the delegation before permitting the connection.
  4. At session end the engineer signs a short statement of what changed.
  5. All three objects verify offline against a published key — no callback, which matters in a substation.

The evidence map to bring to your next audit

What each artefact can actually demonstrate. Fill this in for your own environment before an engagement, not during one.
Question an auditor asksFirewall ruleJump host recordingAuthorization receipt
Was vendor access restricted?YesPartiallyNo — different control
Was there a session on this date?YesYesYes
Can you terminate an active session?YesYesYes, and revocation is itself signed
Who inside the entity authorised it?NoNoYes, by name
What was the permitted scope?NoNoYes, explicitly
When was it meant to expire?NoNoYes
Can we verify this without your systems?NoNoYes

Counting sessions before you argue about controls

One measurement first. Most entities undercount vendor sessions by an order of magnitude because they count vendors, or contracts, rather than connections.

  1. Pull 90 days of remote access logs for every low-impact site.
  2. Count distinct sessions by vendor and by asset.
  3. Cross-reference against work orders or maintenance records.
  4. Report the ratio of sessions to documented authorisations.

That ratio is the number that moves a board. It is not a security argument, which boards discount; it is a control-environment argument, which they do not.

Being clear about scope

Nothing here delivers NERC CIP compliance and nothing here substitutes for a compliance programme. The standards require capabilities this does not provide, and provide for evidence this exceeds.

The argument is narrower and, for a small entity, more useful: the cheapest way to answer the question your auditor actually asks is not a platform. It is a signed record of a decision your staff are already making by email.

Why this lands hardest on small utilities

The tier the extension reached
CharacteristicEffect
Smallest compliance staffOften one person, part-time
Heaviest vendor dependenceLess in-house engineering
Least tooling budgetSession brokers are priced for larger entities
Same evidentiary expectationAt audit

Objections and honest limits

“Our session recordings are the evidence.” They evidence what happened during the session. The question at audit is who at the entity permitted it, which a recording does not contain.

“The vendor's logs cover it.” They are the vendor's records about the vendor's access, produced by the party whose access is in question. That is the weakest form of the evidence.

Producing the evidence cheaply

  1. Make permission an explicit act. Not an implicit consequence of provisioning.
  2. Sign it as a named entity employee. One gesture per session.
  3. Bind the system, scope and window. So the receipt says what was permitted.
  4. Keep the receipt outside the vendor's tooling. So the evidence is yours.

Terms used here

BES Cyber System
A system supporting reliable operation of the bulk electric system, categorised by impact.
Vendor electronic remote access
A supplier connecting remotely to entity systems, the subject of the extended requirements.
Low-impact
The category with the lightest historical requirements, and the smallest compliance functions.

Frequently asked questions

Does CIP-003-9 require authorisation receipts? No. It requires the capability to determine and disable vendor remote access. The receipt exceeds the requirement, and this article is explicit that it does.

We already record sessions. Is that not enough? Session recording documents activity inside a session. It cannot show who inside the entity permitted the session or what scope they permitted, which is what an authorisation question asks.

Does this need connectivity at the substation? No. Verification is offline against a published key, which is a deliberate design choice for environments with unreliable links.

How does this compare to deploying PAM? Privileged access management does considerably more and costs considerably more. For an entity whose only driver is low-impact vendor access, the receipt addresses the audit question at a fraction of the effort.

What changed on 1 April 2026? Vendor electronic remote access controls extended to low-impact BES Cyber Systems — the tier run by the smallest compliance teams.

Do session recordings satisfy it? They evidence the session. They do not evidence which person at the entity permitted it, which is the audit question.

Why not rely on the vendor's logs? Because they are the vendor's records about the vendor's own access — produced by the party whose access is in question.

Where this fits in Manav

Manav binds the operator to the exact command, session or two-person act, verifiable offline at the console or the gateway — which is the condition OT and field work actually run in.

See offline verification →

Sources and further reading