The Order of Return: Rebuilding Trust After a Site-Wide Power Failure

A site-wide power event is usually rehearsed as a facilities problem: generators start, UPS batteries hold, cooling returns, and the estate comes back. For zero-trust programmes, that is the easy part. The harder question is whether identity, policy, certificate and network services return in an order that allows trust to be rebuilt rather than merely reconnected.

Most designs assume a benign sequence. The identity provider is available, devices can reach it, certificates are valid, time is roughly correct, DNS resolves, and policy engines can make decisions. In a cold start, none of those assumptions should be taken for granted. A data centre that has been dark for several hours is not a warm failover. It is a set of dependencies waiting to be discovered in the wrong order.

The cold-start fallacy

Disaster recovery plans often describe recovery time objectives for individual systems. They rarely describe the dependency chain that turns those systems into a functioning trust fabric. An identity provider may restore in twenty minutes, but if administrators cannot reach it because DNS is still converging, the recovery clock has not started. A policy engine may be healthy, but if device certificates cannot be validated because the certificate revocation service is unavailable, enforcement will either fail open or fail closed. Neither outcome is a strategy.

The cold-start problem is therefore not simply about backup power. It is about the order in which trust primitives are restored, and the evidence that each step has actually completed. A status dashboard that shows green for a service with no valid time source or no reachable directory is not assurance. It is decoration.

Five dependencies that decide the order

A practical recovery sequence should begin with the services that other services use to prove basic facts. In most UK enterprise estates, five dependency groups matter.

First, trustworthy time and name resolution. Authentication protocols, certificate validation and log correlation all depend on correct time. If network time is restored from an untrusted source, or if DNS resolution is partial, later steps will produce misleading results. Recovery teams should know which time sources are authoritative, how they are reached, and what happens when they are not.

Second, certificate and key services. Device attestation, service-to-service authentication and administrative access often rely on certificate authorities, revocation endpoints and secrets management. These services need to be available before the systems that consume them, yet they are frequently treated as background infrastructure. A cold start exposes that assumption quickly.

Third, identity and device attestation. The identity provider is necessary but not sufficient. Devices must be able to prove their posture, and administrators must be able to prove theirs. If attestation depends on a management service that is still offline, the organisation may be forced into a temporary trust exception before it has defined one.

Fourth, policy decision points and enforcement points. Policy engines should be restored before or alongside the network paths they govern. If the network fabric returns first and policy returns later, there is a window in which traffic flows without the intended decision. If policy returns first and the network does not, the organisation may believe it is enforcing controls that no user can actually reach.

Fifth, logging and evidence. Recovery is not complete when access works. It is complete when the organisation can show what happened, who accessed what, and which exceptions were used. Break-glass access is a necessary control, but it becomes a liability if the resulting evidence is lost because the logging pipeline was restored last.

A rehearsal, not a tabletop

A cold-start rehearsal should be designed as an operational test, not a discussion exercise. The aim is to discover the real order of dependencies and the points at which human judgement replaces automated policy.

A workable format is a controlled site-level exercise. Choose a non-production environment that mirrors the production dependency chain, or a defined segment of the production estate with change control and supplier support. Simulate a full loss of power to the primary site, including network, compute and management services. Restore services in waves, recording the time at which each service becomes genuinely usable rather than merely pingable.

Include the awkward cases. Test whether break-glass credentials work when the primary identity provider is unavailable. Test whether the service desk can verify an administrator without the usual directory tools. Test whether third-party suppliers can reach their support channels when the organisation's own collaboration platforms are down. Test whether the recovery team can distinguish a restored service from a cached session that has not yet expired.

The output should be a recovery-order map: what must be available before what, which dependencies are hard, which are soft, and where manual intervention is unavoidable. That map is more valuable than a successful demonstration, because it exposes the assumptions that a normal failover test never touches.

Reading the evidence

Resilience teams should define a small set of measures before the rehearsal. Time to first authenticated administrator is useful, but it is not enough. Time to first valid device attestation, time to policy coverage across the restored estate, and time to complete audit evidence are equally important. So is thenumber of break-glass events and the length of time before those events were reviewed.

These measures should be reported in plain language. A board does not need a narrative of every service restart. It needs to know whether the organisation could rebuild trust in a controlled order, where it relied on manual exceptions, and what would have happened if the outage had lasted longer or affected a second site. That is the difference between a recovery story and a resilience argument.

The UK governance context

UK organisations already face expectations around operational resilience, supplier management and cyber assurance. The NCSC's zero-trust principles are helpful precisely because they emphasise explicit verification rather than assumed trust. A cold-start rehearsal turns that principle into an operational question: when the estate returns, how do we verify before we reconnect?

This matters for regulated sectors and for any organisation that has consolidated services into a small number of sites. The more centralised the trust fabric, the more important the restoration order becomes. A site-wide power event is not only a facilities incident. It is a test of whether the organisation can manufacture evidence of trust from a standing start.

Rehearse the return, not just the outage

Most teams know how to respond when systems go down. Fewer have practised how to bring trust back without creating a temporary free-for-all. The next resilience cycle should include a cold-start rehearsal with a defined recovery order, named dependencies and evidence requirements. If the organisation cannot explain why one service must return before another, it has not yet designed recovery. It has only designed restart.