Black start, storm restoration, and the identity provider you cannot reach
Read any utility emergency operating plan and you will find contingencies for degraded communications, degraded SCADA, degraded staffing and degraded transport. You will not find a contingency for degraded identity, because identity is assumed to be available. It is the one assumption the emergency is most likely to break.
What authorises an action when the identity provider is unreachable?
A shared break-glass account, usually. Emergency procedures assume degraded conditions everywhere except identity: during black start or storm restoration, single sign-on is exactly the thing that is unavailable, and the fallback is a credential several people know.
- Federated identity is a synchronous dependency. Authentication requires reaching the provider, and authorization requires reaching policy services.
- The standard fallback — sealed break-glass credentials — reintroduces shared secrets precisely when attribution matters most and scrutiny is highest.
- Offline verifiability is an architectural property, not an availability problem, and it can be tested with a nine-condition partition exercise.
Part of Grid, water and OT identity
The argument, stated bluntly
Utilities have spent fifteen years eliminating shared credentials. Individual accounts, role-based access, multi-factor authentication, privileged session management. Genuine progress, at real cost, against real resistance.
And every one of those programmes maintains, in a safe, an envelope containing a username and a password that works on everything. It is signed out in a logbook. It is the one credential guaranteed to be in use during the events most likely to be investigated afterwards.
That is not hypocrisy. It is the only available answer to a genuine problem. It is also an answer that a different architecture does not require.
Why the dependency exists
Federation works by indirection. The relying system does not evaluate a credential; it asks an identity provider, which asserts something, and the assertion is trusted because of a relationship established in advance. Authorization frequently adds a second call to a policy service.
Both calls are synchronous. Both traverse a network. In a widespread outage — a derecho, an ice storm, a cyber incident that takes the corporate network down alongside everything else — the calls fail, and the systems that depend on them fail closed or fail to a local fallback that is, by construction, weaker.
| Failure | What breaks | Typical fallback |
|---|---|---|
| Identity provider unreachable | Authentication for all federated systems | Cached credentials or local accounts |
| Policy service unreachable | Authorization decisions | Permit-by-default or deny-by-default, neither good |
| Corporate WAN down at a site | Everything above, locally | Sealed envelope |
| Provider outage with no local failure | Same as first row, at a worse moment | Wait, or sealed envelope |
The alternative property: offline verifiability
There is a different way to build authority, and it is not novel — it is how signed software updates, certificate chains and offline payment authorisation already work.
A verifier holds a published public key. An authorisation arrives as a signed statement. The verifier checks the signature locally. No call is made, because the trust anchor was distributed in advance rather than consulted at the moment of use.
That single property changes the contingency planning problem. The question stops being how do we keep the identity provider reachable during a disaster and becomes do our verifiers hold current keys, which is a distribution problem solvable in advance.
The Offline Authorization Readiness Test
Nine conditions. Run this as a tabletop with your identity team and your emergency operations lead. Any answer of we would use the envelope is a finding.
- Identity provider unreachable, local network intact — can a named operator authorise a consequential action?
- Site isolated from the corporate network entirely — same question.
- Provider reachable but policy service down — what is the default, and is it documented?
- Certificate or key expiry occurs during the outage — does the system fail open or closed?
- Mutual aid crew from another utility arrives — can they be authorised without a directory entry?
- An operator's primary device is lost or dead — is a second authenticator enrolled?
- The action must be attributed afterwards — does the record name a human or an account?
- Outage exceeds any cached credential lifetime — what happens at hour 73?
- The event is later investigated — can you demonstrate who did what, from records created during the outage?
Condition five is the one that surprises people. Mutual aid is a defining feature of storm restoration and a structural impossibility for directory-based access control, which is why it is handled today by handing over an account.
Mutual aid, specifically
A crew arrives from three states away to work on your system for six days. They need enough access to do the job and none afterwards. Directory provisioning for a six-day engagement, executed during a storm, is not going to happen, so in practice they are given shared credentials or someone works alongside them holding the keyboard.
A signed, expiring delegation solves this cleanly and is one of the few places where the improvement is immediately obvious to operations rather than to compliance. The visiting crew chief's own credential is delegated a scope, bounded by geography and time, signed by a named person at the host utility. It expires by itself. Nothing needs to be deprovisioned by an exhausted administrator on day seven.
What this does not fix
It does not keep systems available. If the SCADA front end is down, authorisation is not your problem. It does not eliminate the need for a documented emergency procedure, and it does not remove the requirement for local physical control paths that work regardless of any digital system.
It removes one specific thing: the need to keep a shared password in a safe in order to have a contingency at all.
What offline authorisation has to provide
| Requirement | Why |
|---|---|
| Works with no network to an identity provider | That is the condition |
| Attributes the action to a named person | Because the review afterwards will ask |
| Verifiable later by someone who was not there | Regulators and investigators |
| Fast enough for an operator under pressure | Or it will be bypassed |
A signature verified against a locally cached public key satisfies all four. The verifier needs the key, not the issuer, which is precisely the property that makes it work when nothing else does.
Objections and honest limits
“Break-glass accounts are documented and monitored.” Documented, yes. Monitored after the fact, by reading a log that names the shared account. Neither tells you who operated the breaker at 03:40.
“This is a rare scenario.” It is the scenario regulators ask about most closely, because it is when the consequences are largest and the controls weakest.
Preparing offline authorisation
- Test identity unavailability in your drills. Most drills assume it works.
- Cache verification keys locally. On the consoles that will need them.
- Enrol credentials that work without a network. A hardware key does; a push notification does not.
- Reconcile offline receipts when connectivity returns. So the record closes.
Terms used here
- Black start
- Restoring a grid without external power, when supporting systems are least available.
- Break-glass
- An emergency credential granting broad access, typically shared and typically the only offline path.
- Cached verification
- Checking a signature against a locally held public key, requiring no live connection to the issuer.
Frequently asked questions
Is a cached credential not equivalent? No. A cache is a copy of an assertion with a lifetime, and it fails at the end of that lifetime — typically well inside a multi-day event. Offline verification against a published key has no such expiry behaviour.
What if the published key expires during the outage? That is condition four in the test, and it is why dual-key rotation windows exist: two keys valid simultaneously during rotation, so an expiry never coincides with an event.
Does this remove the need for break-glass accounts? For the authorisation problem, largely yes. Organisations may retain emergency accounts for other reasons, but the shared-password contingency stops being the only answer.
How do we get keys onto verifiers? Distribution in advance, the same way you distribute any configuration. It becomes a routine operational task rather than a real-time dependency.
Why is identity the forgotten dependency? Because emergency planning models power, network and systems as degraded, and quietly assumes authentication still works.
What makes a credential work offline? Verification against a locally cached public key. A hardware key works; a push notification requiring a round trip does not.
Why do regulators focus here? Because it is when consequences are largest and controls are weakest, which is also when attribution is most likely to be needed.
Where this fits in Manav
Manav binds the operator to the exact command or clearance, verifiable at the device or the console without a live identity provider — which is the condition OT actually runs in.
Sources and further reading
- Utility emergency operating and restoration plan requirements.
- CISA — known exploited vulnerabilities and incident reporting
- W3C Web Authentication Level 2
- NERC Reliability Standards
- NERC — CIP reliability standards
- CISA — cybersecurity advisories