Break Glass for Machine Identity

Last Updated on September 3, 2026 by Arnav Sharma

Every mature identity programme has a plan for the moment humans cannot sign in. There are two emergency access accounts in a safe, a documented activation path, and a tabletop exercise from last quarter to prove it works. Break glass for machine identity is the same idea applied to the identities that do not have hands: the service principals, managed identities, workload federations and API clients that carry the actual traffic. Almost nobody has built it. The uncomfortable part is that the human plan and the workload plan fail on completely different timescales, and only one of them has been rehearsed.

Between 24 and 26 August 2026 a distributed denial of service campaign against Norway’s Digitalisation Agency made that gap visible at national scale. This article works the failure model properly: the arithmetic of token expiry against issuer downtime, the availability cost of controls designed for compromise, the degraded mode patterns that actually survive contact with an incident, and what you can pre-stage before it happens to you.

Why machine identity break glass is a different problem

The classic emergency access account exists so that a named human can bypass a policy layer that has failed. It has a long random password, a hardware key, no federation dependency, and a permanent role assignment. Microsoft’s own guidance on emergency access for administrators, the AWS cross account reference implementation and Atlassian’s break glass account for isolated cloud tenancies all share the same shape. A person shows up, presents something they physically possess, and gets in.

None of that shape transfers to a workload. Consider what breaks:

• There is no person present. A batch job at 02:00 cannot open a safe. Any workload emergency path has to be pre-staged in a form the workload can consume without human intervention, or it is not a recovery control at all.
• The credential has to be materially different. A break-glass account for an administrator can rely on multi-factor authentication (MFA) with a hardware key because a human carries the key. A workload has no second factor in the same sense. Its second factor is usually network position or an attested runtime, both of which are properties of the environment rather than the identity.
• Failure is silent and delayed. A locked out administrator complains within minutes. A workload that cannot mint a token retries, backs off, fills a dead letter queue and reports nothing until a business process misses a deadline hours later.
• The blast radius is wider by design. The human emergency path is scoped to restoring administrative control. A workload fallback has to actually run production traffic, which means it needs the permissions that traffic needs, not a narrow recovery role.
• Scale changes the governance. Two dormant human accounts fit in a safe. Four hundred workloads do not fit in any process that involves a human approving each activation.

Break glass access for people is well documented, and the published best practices are mature. The challenges with break glass in a workload context are different in kind rather than in degree, which is why copying the human pattern produces something that looks like a control and behaves like a gap.

This is where identity security programmes quietly diverge from reality. Identity and access management maturity models measure whether emergency accounts exist, whether they are excluded from conditional policies, and whether their use raises a notification. All of those questions have the word “account” in them and all of them assume a user account with a person behind it. Modern identity estates run far more non-human principals than human ones, and the resilience question for those principals was never asked.

The arithmetic nobody runs: what happens at minute 61

Here is the exercise that separates a real design from a paragraph in a policy document. Take one integration. Write down the lifetime of the token it uses. Write down how long you assume your issuer could be unreachable. Subtract.

If your service to service tokens live 60 minutes and the token service is degraded by a 60 hour outage, the interesting question is not whether you survive. It is what happens at minute 61, and then what happens for the following 59 hours, per integration, in dependency order.

Most teams have never written this down, so the answer is discovered live. Three variables decide the outcome:

1. Effective token lifetime. Not the configured value, the value in the token you are actually holding. Microsoft Entra ID issues a default access token lifetime of one hour where Continuous Access Evaluation is not negotiated, with deliberate variation applied to spread renewal demand. Maskinporten issues self contained tokens that its own documentation describes as non revocable and therefore short lived, with client assertion grants capped at 180 seconds. AWS security token service sessions from a web identity assertion are commonly 900 seconds.
2. Refresh behaviour. Libraries do not wait until expiry. Microsoft Authentication Library refreshes proactively at roughly half the token lifetime for long lived tokens and holds the existing token if the issuer is unreachable, which converts a short disruption into a non event. Hand rolled clients that fetch on demand and cache nothing convert the same disruption into an immediate failure.
3. Backend caching. Managed identity token requests are served through a platform layer that maintains its own cache per resource, which is why permission changes can take hours to appear. That cache is invisible in your architecture diagram and it is doing more for your survivability than any control you designed.

Worked survival windows

The table below models one integration at a time. The survival window is the interval between the start of the disruption and the first failed business operation, assuming no fallback exists.

Integration pattern	Effective token lifetime	Refresh trigger	Survival window	First visible symptom
Managed identity to platform API, modern SDK	24 hours, platform cached	Half life, holds on failure	12 to 24 hours	Nothing until cache expiry, then broad failure
Service principal with client secret, MSAL	60 to 90 minutes	Half life, holds on failure	60 to 90 minutes	Silent retries, then authentication errors
Workload identity federation to external issuer	60 minutes, chained	Both issuers must be reachable	Shortest of the two	Federation exchange fails before token expiry
Hand rolled client, fetch per call	Effectively zero	Every request	Under one minute	Immediate errors on first call
National token service client, 120 second tokens	2 minutes	Every two minutes	Under 5 minutes	Batch submissions fail, queue depth climbs
Certificate authenticated client, long assertion	60 minutes	Half life	30 to 60 minutes	Errors after first missed renewal

Two conclusions fall out of this table that are worth arguing about in a design review.

First, the workloads with the best survivability are the ones you did the least work on, because a platform cache is carrying them. The workloads you hardened with tight lifetimes are the ones that die first.

Second, workload identity federation is the worst case in the list and it is the pattern everyone is migrating towards. A federated exchange requires both the external issuer and the token service to be reachable at the same moment. You have taken two availability risks and multiplied them, in exchange for eliminating a stored secret. That is usually the right trade. It is rarely made explicitly.

The paradox: short token lifetimes are right for compromise and wrong for availability

Every piece of guidance you have read says to shorten token lifetimes and adopt Continuous Access Evaluation. That guidance is correct and it optimises for exactly one failure mode.

Short lifetimes limit how long a stolen token is useful. Continuous Access Evaluation goes further: it lets a resource subscribe to critical events from the issuer so that revocation happens in near real time rather than waiting for expiry, and in exchange Microsoft extends token lifetime to as much as 28 hours. Read that trade carefully, because it points in an unexpected direction. Enabling Continuous Access Evaluation makes your tokens longer lived, not shorter. Lifetime stops being the control and revocation becomes the control.

For availability, that is a gift. A 28 hour token survives a 30 hour disruption for most of its duration. But the gift is narrow. Continuous Access Evaluation is implemented by participating resources subscribing to issuer events, which in practice means first party services and Microsoft Graph. A custom internal API does not participate unless someone builds it, and the tenant wide configurable token lifetime policy is not honoured for sessions that do negotiate it. So you end up with a split estate: some traffic on long lived revocable tokens that ride out a disruption comfortably, and the rest on one hour tokens with no revocation channel at all.

Nobody in your organisation has drawn that boundary on a diagram. It is the single most useful artefact you can produce this week. Write down which of your resources are on the long lived revocable path and which are not, because that line is also the line between workloads that survive a multi hour issuer failure and workloads that do not.

The security controls that make token theft survivable and the ones that make issuer downtime survivable pull in opposite directions. Pretending otherwise is how teams end up surprised.

The change you cannot make during the incident

The instinctive response, once the first errors appear, is to extend token lifetimes until the disruption clears.

You cannot. Token lifetime is a property enforced by the component issuing tokens. If that component is unreachable, the administrative call that changes the policy is unreachable too. Even where the control plane is separate from the token endpoint and remains responsive, the policy only applies to tokens issued after the change, and issuing tokens is precisely what is not working. The lever exists and it is welded shut at the exact moment you want to pull it.

The same trap catches several other reflexes. You cannot rotate to a backup secret if the rotation workflow authenticates through the failed issuer. You cannot deploy a configuration change if your pipeline’s own identity comes from the same place. You cannot page the on call engineer through a tool that uses the same single sign on. Dependency mapping for identity failure is different from dependency mapping for application failure, and most continuity plans only model the second.

Everything useful therefore has to be decided and staged before the incident. That is the entire argument for a break glass process for workloads: not that dormant emergency material is pleasant to own, but that the alternative is a set of controls you cannot operate when you need them.

Degraded mode patterns for workload token issuance

Four patterns are viable. None is free, and the honest position is that most workloads should get pattern zero, which is failing cleanly.

Pattern	How it works	Recovery time	Standing risk	Best fit
Fail clean and queue	Workload detects issuer failure, stops, persists work, replays on recovery	Bounded by queue durability	None	The large majority of workloads
Extended cache with stale token tolerance	Client holds the last valid token past normal refresh, resource accepts modest clock tolerance	Bounded by original lifetime	Low, expiry still applies	Read heavy internal traffic
Pre-staged secondary credential	A dormant certificate or secret registered against a second issuer or region, activated by configuration	Minutes	Moderate, live material exists	Tier one revenue or safety paths
Local issuance fallback	A constrained local token authority issues narrowly scoped tokens the resource will accept during a declared incident	Minutes	High, a second trust root exists	Rare, and only with a full design review

The pre-staged secondary credential is where most organisations should stop. It gives you controlled emergency access to token issuance without inventing a parallel trust hierarchy. The mechanics matter: it must be registered in advance, must not be reachable by the same automation that manages routine credentials, and must be stored securely in a location that does not itself depend on the failed issuer for retrieval. A secret vault that authenticates through the very issuer you are trying to work around is not a fallback. It is the same dependency wearing a different hat.

Local issuance fallback deserves a warning. A second trust root that resources will accept is, functionally, a permanent bypass of your primary identity control. It converts an availability problem into an authorisation problem and hands attackers a target worth far more than any single secret. If you build it, the resources that accept the fallback issuer should be an explicit allowlist, the fallback should be inert until a signed incident declaration activates it, and the whole assembly should be reviewed as though it were an external federation, because it is.

Which workloads justify a secondary issuance path

The instinct to protect everything is the fastest route to protecting nothing. Break glass credentials are dormant sensitive material, and every one you create is another thing to inventory, rotate and defend. Dormant emergency identities and their workload equivalents are consistently among the most attractive targets for attackers precisely because they sit outside routine controls.

Tiering reduces the risk you carry, because every fallback you skip is dormant material an attacker cannot gain access to. Tier your workloads before you build anything.

Tier	Criteria	Recommended pattern	Review cadence
Tier 0	Safety of life, regulatory hard deadline, or loss of ability to restore other systems	Pre-staged secondary certificate plus tested activation	Quarterly, with live test
Tier 1	Direct revenue impact within the assumed downtime window, or contractual availability commitment	Extended cache tolerance, secondary path only if the arithmetic fails	Half yearly
Tier 2	Internal operations that degrade gracefully, reporting, analytics, non urgent synchronisation	Fail clean and queue	Annual review of queue durability
Tier 3	Everything else	Fail clean, no queue, accept replay from source	None

The tiering question that catches people is the second one in the Tier 0 row. Ask which of your workloads are required to restore the others. Backup orchestration, configuration management, certificate renewal, monitoring and the deployment pipeline are all workloads with identities, and if they are down you cannot fix anything else. They belong in Tier 0 regardless of their apparent business criticality, because they are the path back to access to critical systems. Restoring them is how you regain control of everything downstream.

A short arithmetic check settles most Tier 1 arguments. If the survival window from your table exceeds your assumed worst case downtime with margin, you do not need a secondary path. The Norwegian incident ran past thirty hours in waves and the estimate you choose should reflect that, not the four hour figure most business continuity plans still carry.

What to pre-stage now

None of this requires a programme. It requires an afternoon and a decision.

1. Build the survival window table for your top twenty integrations. Effective lifetime, refresh behaviour, survival window, first symptom. This artefact alone will change the conversation.
2. Map the identity dependency graph, not the application dependency graph. Include your vault, your pipeline, your paging tool and your monitoring. Mark every point where a recovery action authenticates through the thing that failed.
3. Draw the Continuous Access Evaluation boundary. List which resources are on long lived revocable tokens and which are not.
4. Register Tier 0 secondary certificates before you need them. A dormant certificate registered today costs nothing. Registering one during an incident requires the issuer that is down.
5. Write the emergency access procedures for workloads, not just people. Who declares, what configuration flips, what the rollback looks like, and how you confirm every fallback is dormant again afterwards.
6. Nominate an emergency account manager. One accountable owner for the inventory of dormant workload and human access credentials, their rotation, and their attestation. Distributed ownership means nobody rotates anything.
7. Test with the issuer blocked, not with the secret removed. Blocking network egress to the token endpoint from one non production workload reproduces the real failure. Deleting a secret does not.
8. Rehearse the human side too. Validate that your regular admin accounts, your privileged accounts and your two dormant break glass accounts still work, and that the people who would use them have practised. Machine identity resilience does not replace the human plan.

Set an expiry on every item you stage. Dormant privileged material that nobody has attested in a year is not an emergency access solution, it is an unmanaged risk with good intentions attached.

Detecting misuse of workload emergency material

A dormant credential that nobody watches is worse than none at all. The detection requirement is narrow, which makes it achievable: these identities should be used approximately never, so any use is worth investigating.

Forward the relevant sign in and audit telemetry to your security information and event management platform and build against these signals. Route each alert to a team that is awake, and fold the response into your incident response runbook so the notification lands somewhere with a defined next step. Every detection in the table is high signal precisely because the baseline is zero.

Signal	Why it matters	False positive profile
Any authentication by a dormant workload emergency identity	Baseline is zero outside declared incidents	Quarterly validation tests, planned exercises, expiry monitoring probes
Access to break glass accounts or their stored material in the vault	Retrieval precedes use	Auditors sampling controls, rotation automation, onboarding walkthroughs
Fallback identity used outside a declared incident window	Correlates use against the incident record	Clock skew between the incident record and telemetry, incidents declared retroactively
Token requests from unexpected network or workload origin	Pre-staged material is location bound by design	Legitimate failover to a secondary region, infrastructure migration
Permission grant added to a dormant identity	Scope creep converts dormant material into standing privilege	Automated policy baselines applying tenant wide changes
Fallback still active more than 24 hours after incident closure	The most common real world finding	Extended incidents, staged recovery where some workloads lag

The break glass scenarios that end in security breaches are almost always the ones where the emergency path stayed active after the incident closed, so the last row of that table deserves a standing alert of its own. Test each rule against your own change calendar before enabling notifications, because the dominant false positive source is your own validation activity. That is a solvable problem: exclude a named test window rather than the identity itself, so that the identity is never excluded permanently.

Pair detection with the boring discipline. Activation should be restricted to named authorized personnel and recorded as a decision, not a shrug. Emergency paths exist for outages and for security incidents alike, and the same material carries elevated privileges in both cases, which is exactly when standard access controls cannot be applied and something else has to hold the line. A breach of that material is a worse day than the disruption it was built for. Least privilege on the dormant identity, scoped to exactly the operations the fallback must perform. Time bound activation. Rotation after every use, including tests. Separation between the identity that holds break glass account credentials and the identity that manages them. Privileged access management tooling handles most of this for human accounts already, and extending its inventory to cover workload emergency material is usually a configuration exercise rather than a purchase.

Closing position

The Norwegian incident is not interesting because a government service went down. It is interesting because a national machine to machine token service was degraded for the better part of three days and almost every account of it discussed people logging in.

Human sign in failure is visible, loud and rehearsed. Workload token issuance failure is quiet, delayed and almost never modelled. If you take one thing from this: build the survival window table for your top integrations this week, and see whether the answer at minute 61 is one you would be comfortable defending. In most estates it will not be, and the fix for the majority of workloads is not a new secret. It is deciding, in advance and in writing, that they are allowed to fail cleanly.