Notifications
Clear all
Topic starter
30/07/2026 10:47 pm
TL;DR: The October 2025 AWS outage showed how dependency failures can halt services when core infrastructure goes offline, and the same risk exists inside identity platforms when tenant recovery is treated as optional, according to Acsense. Recovery assumptions break when IAM availability, configuration integrity, and backup discipline are not governed as business continuity controls.
NHIMG editorial — based on content published by Acsense: the AWS outage of October 2025 and IAM resilience in shared responsibility models
By the numbers:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
- Only 5.7% of organisations have full visibility into their service accounts.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
Q: What breaks when IAM tenant recovery is not in place?
A: When IAM tenant recovery is missing, the organisation can lose access to the configuration that controls login, authorisation, and administrative recovery.
Q: Why do identity systems need their own resilience plan?
A: Identity systems need their own resilience plan because vendor restoration only brings the platform back, not your tenant state.
Q: How do you know if IAM backup is actually working?
A: IAM backup is working only if you can restore critical objects and complete a realistic recovery exercise.
Practitioner guidance
- Inventory identity control-plane dependencies List every tenant, admin boundary, federation link, and tier-0 application dependency so you know which identity objects would stop business operations if lost.
- Back up configuration state with immutable versions Capture policies, groups, roles, app assignments, conditional access rules, and trust settings in immutable, versioned backups stored outside the primary tenant boundary.
- Define restore objectives for critical identity flows Set separate recovery targets for user login, admin login, break-glass access, and federation rollback, then test each path against actual restore times.
What's in the full article
Acsense's full blog covers the operational detail this post intentionally leaves for the source:
- A practical IAM disaster recovery blueprint for Okta, Entra ID, or Ping tenants
- Step-by-step guidance for backing up groups, policies, app assignments, and trust settings
- Restore playbooks for broken MFA policy, deleted admin groups, and federation rollback
- Board-ready metrics for time-to-restore, configuration drift, and recovery evidence
👉 Read Acsense's analysis of IAM resilience after the AWS outage →
IAM resilience in shared responsibility models: are your controls ready?
Explore further
30/07/2026 10:52 pm
IAM resilience is a governance control, not a platform feature: The article is right to separate hyperscaler recovery from tenant recovery, because the customer controls the identity layer they configure and depend on. That makes restore readiness an identity governance issue, not just an infrastructure backup issue. The implication is that IAM continuity must be treated as part of operational control ownership, not vendor assurance.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means many identity programmes still lack complete recoverability and ownership mapping.
A question worth separating out:
Q: Who is accountable when tenant-side IAM disruption causes downtime?
A: The customer is accountable when tenant-side IAM disruption causes downtime because the tenant configuration, recovery design, and restore testing are under customer control. NIST CSF 2.0, DORA, and NIS2 all point in the same direction: continuity evidence must cover the identity layer, not only infrastructure uptime.
👉 Read our full editorial: IAM resilience is the missing layer in cloud shared responsibility
