When should organisations allow tokenless access during an attestation outage?

When tokenless access is ever justified

Tokenless access should be treated as an exception, not a normal fallback. The only defensible case is when the organisation has already approved a continuity path, the exception is narrowly scoped, and the access path is time-bound with clear expiry. Without that preapproval, tokenless requests should fail closed because they remove the proof-of-authority step that normally constrains access.

That means the question is not whether the token is inconvenient during an outage, it is whether the organisation has accepted a temporary reduction in assurance for a specific business purpose. If the answer is yes, the fallback should be explicit, monitored, and easy to revoke; if not, the outage is not a reason to weaken access control.

Why attestation outages change the control decision

An attestation outage breaks the system’s ability to verify the credential or workload assertion that normally stands behind the request. In practice, this can affect service-to-service authentication, workload identity validation, or any control that depends on a live trust check. If teams silently bypass that check, they may preserve availability at the cost of turning a controlled access path into an unaudited exception path.

Good continuity design separates service continuity from blanket trust. The fallback should preserve as much verification as possible, even if it cannot complete the full attestation flow, and it should be limited to the smallest set of systems and operations needed to keep the business running. That is especially important where the request is for privileged, cross-system, or production access.

When the fallback is well designed, the outage becomes a managed degradation rather than a control collapse. When it is poorly designed, tokenless access can create broad standing access that outlives the incident and becomes difficult to distinguish from legitimate activity later.

What tokenless access should look like in practice

Tokenless access, if authorised at all, should be tied to a preapproved exception policy, a named owner, and a defined end time. The exception should also be limited to the minimum business function needed during the outage, rather than opening the same scope the token would normally authorise.

The fallback should be observable enough that teams can tell when it is active, which systems used it, and when it was shut off. If the organisation cannot answer those questions quickly, the exception is too loose to be safe. In that case, it is usually better to keep the control in place and let the business tolerate a short delay than to create a broader access path that is hard to unwind.

Where possible, organisations should pair the exception with stronger monitoring, shorter review intervals, and a post-incident review of whether the fallback was actually needed. That review should confirm whether the attestation service failed cleanly, whether the request pattern changed during the outage, and whether the exception scope was larger than the operational need.

Risk and Threat Considerations

Tokenless access is risky because it removes the normal assurance that the caller is the authorised party for that request. During an outage, attackers and insiders can both benefit from the same control gap, especially if the business has already created a precedent for bypassing verification when systems are under pressure.

Failure mechanism: A degraded attestation path is treated as permission to bypass the token check entirely, which creates an easy abuse path for unauthorised access, privilege escalation, or undetected reuse of a standing fallback.

Impact: The organisation may preserve availability in the short term, but it can also expose sensitive systems to uncontrolled access, weaken auditability, and make it harder to prove who accessed what while the exception was open.

Practitioner Guidance

Decision rule: If the continuity policy does not explicitly name the fallback, do not improvise one during the outage. If it does, verify that the exception is time-limited, scope-limited, and owned by a named approver before you allow it.

What to verify: Confirm that the exception can be detected in logs, revoked quickly, and reviewed after the incident. If you cannot prove when tokenless access started and stopped, the control is too weak for production use.

Practitioner takeaway: The safe default is fail closed; tokenless access only becomes acceptable when the organisation has already accepted the risk, bounded the exception, and preserved enough visibility to unwind it cleanly.

Related resources from NHI Mgmt Group

• How should organisations design identity access so users can still authenticate during a cloud outage?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?