Notifications
Clear all
Topic starter
06/06/2026 1:52 am
TL;DR: DHS found that avoidable NHI management failures, including a forgotten signing key left unrotated for more than six years and reused across business and consumer systems, helped enable the Storm-0558 compromise of Microsoft Exchange Online accounts, according to Oasis Security's summary of the report. Manual key management is no longer a tolerable control model when one stale credential can collapse cloud-wide trust.
NHIMG editorial — based on content published by Oasis Security covering the Microsoft Exchange incident and non-human identity management failures
Questions worth separating out
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.
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.
Q: What do security teams get wrong about manual key rotation?
A: They treat rotation as a periodic task instead of a lifecycle control.
Practitioner guidance
- 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.
- Automate rotation for long-lived secrets Move privileged keys, certificates, and tokens onto rotation schedules enforced by tooling rather than manual tickets.
- Revalidate inherited identities after change events Treat mergers, platform migrations, and vendor transitions as triggers for full NHI reclassification.
What's in the full report
Oasis Security's full blog post covers the operational detail this post intentionally leaves for the source:
- The report timeline and incident chronology for Storm-0558, including detection, notification, and key invalidation milestones.
- The discussion of why Microsoft shifted from manual to automatic key rotation after the incident.
- The article's lifecycle framing for provisioning, rotation, and decommissioning of non-human identities.
- The surrounding commentary on automation, continuity, and why manual processes fail at NHI scale.
👉 Read Oasis Security's analysis of the Microsoft Exchange incident and NHI exposure →
Microsoft Exchange and NHI rotation: what IAM teams need to fix?
Explore further
06/06/2026 3:13 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Microsoft Exchange breach exposed the limits of manual NHI rotation
