Microsoft Exchange breach exposed the limits of manual NHI rotation

At a glance

What this is: This is an analysis of the DHS review of the Microsoft Exchange incident, which found that stale, reused, and poorly governed non-human identities helped enable the compromise.

Why it matters: It matters because service account, key, and token governance failures can create enterprise-scale exposure, and the same lifecycle gaps also show up in human IAM and autonomous identity programmes.

👉 Read Oasis Security's analysis of the Microsoft Exchange incident and NHI exposure

Context

Non-human identity management breaks down when teams treat keys, tokens, and signing material as static infrastructure instead of governed identities. In the Microsoft Exchange incident, that assumption failed: a privileged key was forgotten, left in place across environments, and not retired when its operational context changed. This is a classic NHI governance problem, not just an incident response problem.

The deeper issue is lifecycle discipline. Discovery, rotation, decommissioning, and risk review have to be linked, or a single credential can remain trusted long after the business process that created it has moved on. That pattern is typical in large environments where continuity pressures outrun identity controls.

Key questions

Q: What breaks when a privileged signing key is left unrotated for years?

A: A forgotten signing key turns into a durable trust anchor that attackers can abuse to mint or validate access across services. The failure is not just exposure, but the persistence of trust long after ownership and intent have drifted. That creates broad compromise potential from one stale credential.

Q: Why do service-account and signing-key failures create such large blast radius?

A: Because one credential can authenticate many systems when identity trust is centralised. If the same key or token is reused across environments, a single compromise can extend into mail, cloud apps, and administrative workflows. The larger the trust chain, the harder it is to contain the breach.

Q: What do security teams get wrong about manual key rotation?

A: They treat rotation as a periodic task instead of a lifecycle control. In reality, manual rotation depends on memory, low operational friction, and clear ownership, all of which degrade at scale. Without automation, rotation often happens too late or not at all.

Q: Who is accountable when inherited NHI credentials remain active after a merger or acquisition?

A: Accountability sits with the team that owns identity governance after the change event, not the team that originally created the secret. Inherited credentials must be revalidated, assigned, or retired quickly because legacy trust does not expire on its own. This is exactly the kind of control gap that lifecycle reviews should catch.

Technical breakdown

How stale signing keys become cloud-wide trust anchors

A signing key is not just a secret, it is a trust primitive. In cloud identity systems, a valid signing key can mint or validate authentication material that downstream services accept as proof of legitimacy. If the key is shared across multiple environments, or if rotation stops, the blast radius expands from one service to every system that trusts the same issuer. This is why abandoned keys are especially dangerous in federated identity architectures: compromise is not limited to a single login, but to whatever can be authenticated with the key's authority.

Practical implication: inventory which keys can mint trust for multiple systems and retire any that still span unrelated environments.

Why manual key rotation fails at NHI scale

Manual rotation depends on human memory, operational windows, and change discipline. That model breaks down when the number of identities grows faster than the people assigned to maintain them. In practice, teams defer rotation to avoid outages, and the secret stays live long enough to become organizationally invisible. The result is not simply weaker hygiene, but a governance gap where ownership, frequency, and retirement date are no longer enforced by the system.

Practical implication: replace ad hoc rotation with automated, lifecycle-bound controls that enforce expiry and decommissioning.

What happens when acquired or inherited identities are not reassessed

Acquisitions and platform transitions often leave inherited identity material outside normal review paths. If an old signing key or service credential remains trusted after the business context has changed, the organisation effectively preserves access that no one is actively accountable for. This is one of the most common NHI failure modes because the credential looks operational, even when the process that legitimised it has ended. The technical issue is not simply exposure, but trust persistence without revalidation.

Practical implication: force post-acquisition identity revalidation for every inherited key, token, and certificate.

Threat narrative

Attacker objective: The objective was long-lived access to high-value email accounts for espionage and intelligence collection.

1. Entry occurred when Storm-0558 exploited authentication tokens associated with a Microsoft signing key established in 2016 and still trusted in 2023. Credential access was possible because the key had been left in place and not rotated for years, giving the attacker valid trust material rather than a broken password. Impact followed when the actor accessed Exchange Online mailboxes across multiple organisations and used that access to reach sensitive government email accounts.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Manual rotation is an assumption, not a control, and it failed here. Manual key rotation assumes operators will notice when a secret outlives its purpose, remember to rotate it, and safely execute that work before exposure becomes material. That assumption failed when a highly privileged signing key remained valid for years. The implication is not merely that automation is helpful, but that human-paced review cycles are structurally mismatched to NHI trust material.

Cross-environment key reuse creates identity blast radius. A single signing key used across business and consumer contexts turns one credential into a shared trust anchor. When that key is compromised, compromise propagates across every system that accepts the same trust chain. Practitioners should treat shared signing material as a blast-radius decision, because reuse converts a local failure into an ecosystem failure.

Inherited NHI assets are a lifecycle blind spot. Acquired or legacy identities often survive beyond the business process that created them, especially when no one re-establishes ownership after organisational change. That is not a missing best practice in the abstract, it is a failure of accountability continuity. The practical conclusion is that every inherited secret, certificate, and signing key must be reclassified as active risk until proven otherwise.

Automation is now a baseline expectation for NHI governance at scale. This breach reinforces that manual processes do not keep pace with the number, lifespan, and interdependencies of machine identities. The field should stop treating automation as an optimisation and start treating it as the only viable way to maintain decommissioning, rotation, and visibility over time.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
• Security teams should use the 52 NHI Breaches Analysis to pressure-test whether stale signing material can still reach production trust paths.

What this signals

Manual governance is becoming the limiting factor in NHI risk management. When organisations rely on human rotation cadence, they inherit the same blind spots that showed up in the Microsoft Exchange incident. The practical shift is toward lifecycle automation, because secrets that can outlive their owners also outlive review cycles.

The scale problem is already visible in the data: 72% of organisations have experienced or suspect they have experienced a breach of non-human identities. That makes the issue a programme design problem, not a niche incident pattern, and it argues for stronger inventory, ownership, and retirement controls across the secret estate.

Identity blast radius is the concept teams should watch. Once a single signing key can authenticate across multiple environments, remediation becomes a containment exercise as much as a rotation exercise. Teams that map trust chains now will be better prepared when the next inherited key, certificate, or token appears outside normal change control.

For practitioners

• Map signing-key trust chains Identify every service, tenant, and application that accepts the same signing authority, then document where one key can authenticate multiple environments. Prioritise keys that bridge consumer and business contexts because they create outsized blast radius.
• Automate rotation for long-lived secrets Move privileged keys, certificates, and tokens onto rotation schedules enforced by tooling rather than manual tickets. The goal is to ensure rotation happens before the secret becomes invisible to the owning team.
• Revalidate inherited identities after change events Treat mergers, platform migrations, and vendor transitions as triggers for full NHI reclassification. Every inherited credential should be reviewed for ownership, purpose, and retirement status before it remains trusted.
• Block cross-domain secret reuse Prevent the same key material from authenticating unrelated production domains. Where reuse already exists, segment the trust path and replace the shared secret with separate identities tied to distinct scopes.

Key takeaways

• This incident showed that one forgotten signing key can remain a live trust anchor for years and create enterprise-wide exposure.
• The scale of the problem is not theoretical, because compromised non-human identities are common enough to show up across most organisations.
• Automation, lifecycle reassessment, and cross-environment trust mapping are the controls most directly tied to preventing this failure mode.

Key terms

• Non-Human Identity: A non-human identity is a machine credential used by software, services, or infrastructure rather than a person. In practice it includes keys, tokens, certificates, and service accounts that authenticate workloads and sign trust decisions. These identities need ownership, lifecycle control, and rotation just like human accounts.
• Signing Key: A signing key is a secret used to create or verify trusted authentication material. When that key is tied to identity infrastructure, it can become a high-value trust anchor that affects many systems at once. If it is reused or left unrotated, compromise can spread far beyond the original service.
• Identity Blast Radius: Identity blast radius is the scope of systems exposed when one credential, token, or certificate is abused. It is determined by how broadly the secret is trusted, how many environments share it, and whether lifecycle controls limit its reach. Smaller blast radius means fewer downstream systems inherit the failure.
• Lifecycle Decommissioning: Lifecycle decommissioning is the controlled removal of an identity when its purpose ends or its trust context changes. For non-human identities, this includes revoking keys, retiring certificates, and removing downstream dependencies that still accept the old credential. Without it, stale trust persists as hidden risk.

Deepen your knowledge

NHI lifecycle automation and secret rotation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is still managing signing keys and tokens with manual processes, this is the right place to start.

This post draws on content published by Oasis Security covering the Microsoft Exchange incident and non-human identity management failures. Read the original.