Authn and Authz expose the limits of human-scale IAM

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Opal Security's blog post: Weak authentication and excessive authorization combine into one failure path, as the Deloitte breach shows.

Why it matters: It matters because IAM teams cannot treat login assurance and privilege control as separate workstreams when one weak account can still open a wide blast radius.

👉 Read Opal Security's analysis of authn and authz under modern IAM pressure

Context

Authentication proves an identity is who it claims to be, while authorization determines what that identity can do after access is granted. In IAM programmes, those controls only work when verification, privilege scope, and account lifecycle are governed together rather than as isolated functions.

The article uses the Deloitte breach as a cautionary example of what happens when password-only access meets unrestricted permissions. That is a classic IAM failure mode, not a niche edge case, because similar control gaps can affect human users, admin accounts, and non-human access paths when governance is too loose.

Key questions

Q: What breaks when authentication is too weak but authorization is broad?

A: One compromised identity can become a full environment compromise when a stolen credential opens broad permissions. Weak authentication increases the chance of entry, but oversized authorization determines the blast radius after entry. IAM teams need to evaluate both controls together, because a strong password policy cannot compensate for permissions that were never meant to be that broad.

Q: Why do overprivileged accounts make breaches harder to contain?

A: Because the compromise of one account becomes the compromise of whatever that account can already reach. Broad permissions shorten an attacker’s path to sensitive systems, increase lateral movement options, and make detection slower to matter. Least privilege reduces the blast radius by limiting what a stolen identity can do.

Q: What are the signs that authorization governance is failing?

A: Common signs include conflicting permissions across applications, frequent code changes for access rules, difficulty answering audit questions, and teams relying on custom logic to grant or block access. Those symptoms show the policy plane is fragmented, which usually means governance is lagging behind application development.

Q: Should organisations treat MFA and least privilege as one programme or two?

A: They should treat them as one programme because authentication and authorization work as a single control chain. MFA reduces the chance of impersonation, while least privilege limits what the impersonator can do if the first control fails. Splitting them into separate workstreams creates gaps that attackers can exploit between login assurance and entitlement scope.

Technical breakdown

Authentication fails when a single factor carries the session

Authentication is the proof step that accepts a claimed identity, but password-only authentication gives attackers the same access the legitimate user has once the secret is stolen. Multi-factor authentication reduces that risk by requiring another proof signal, yet not all factors are equivalent. Hardware keys and token-based methods resist phishing and interception better than SMS or email codes. In practice, the question is not whether authentication exists, but whether the chosen factor actually raises the cost of impersonation enough for the asset being protected.

Practical implication: remove password-only access from high-value accounts and reserve weaker factors for low-risk use cases only.

Authorization fails when permissions outgrow the role

Authorization is the policy layer that decides what an authenticated identity may reach, modify, or delegate. In mature IAM, that decision depends on a clear asset inventory, data classification, and controlled provisioning and deprovisioning. When permissions are broad, inherited without review, or tied to stale role design, one compromised account becomes a pivot point rather than a contained endpoint. RBAC, ABAC, and related models only work when the underlying entitlement set matches the real job function and resource sensitivity.

Practical implication: review privileged roles against actual task scope and remove any entitlement that is not required for routine work.

Emergency access is not a substitute for governed privilege

Break-glass access exists for exceptional recovery, but it can become dangerous if it starts behaving like ordinary authorization. Once emergency paths are loosely defined, poorly monitored, or reused for convenience, they blur the line between temporary recovery and standing privilege. That weakens accountability because the system no longer distinguishes crisis access from normal access. The Deloitte example shows the opposite problem at scale: too much access was already present, so attackers did not need an emergency path at all. Both conditions point to the same governance flaw, which is uncontrolled access scope.

Practical implication: separate emergency access from routine privilege and make every exception auditable, time-bound, and tightly scoped.

Threat narrative

Attacker objective: The attackers sought persistent access to internal systems and sensitive data by turning one compromised identity into broad operational reach.

1. Entry occurred when attackers compromised an email administrator account that was protected only by a single password.
2. Escalation followed because that account had unrestricted access, allowing the attackers to move from authentication compromise to broad internal reach.
3. Impact came from months of undetected access during which sensitive information was stolen from Deloitte systems and downstream organizations were exposed.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authentication and authorization are no longer separable controls in modern IAM: the Deloitte case shows that identity proof and privilege scope fail together when one account is overtrusted. A password can open the door, but excessive authorization decides how far the attacker can move once inside. The implication is that IAM programmes must be judged on the combined control plane, not on login success rates alone.

Privilege breadth, not just credential strength, determines the blast radius of account compromise: Deloitte's email administrator account was not merely authenticated weakly, it was authorised too broadly. That is the governance failure that matters, because a strong login does not compensate for a permission model that assumes trust after entry. Practitioners should read this as a warning about entitlement design, not only about MFA adoption.

Access review cadences do not fix structurally oversized roles: if the role itself is overpowered, recertification only repeats the same mistake on a schedule. The breach shows that role design, deprovisioning hygiene, and exception handling must be treated as first-class controls. For identity programmes, this is a reminder that governance has to reshape the entitlement baseline, not merely inspect it periodically.

Human-scale IAM breaks when the environment is larger than the reviewer can reason about: the article's central finding is that manual thinking about access no longer matches the size and speed of modern systems. Authn and Authz still matter, but their governance must be contextual, continuous, and tied to asset criticality. The practitioner conclusion is simple: treat identity as an operating model, not a login feature.

Overbroad authorization is the hidden control failure behind many identity breaches: the named concept here is the identity blast radius, meaning the amount of damage one compromised account can cause. Deloitte demonstrates that the blast radius is determined less by compromise itself than by the permissions attached to the account. Practitioners should use that lens when assessing whether their IAM design contains failure or amplifies it.

What this signals

Identity blast radius is the right way to think about this class of failure: the core question is not whether an account can be compromised, but how far it can move once compromised. When authorization is broader than the real job function, one stolen credential becomes a systemic event rather than a local incident.

IAM teams should expect more scrutiny on the relationship between proofing strength and entitlement design. The practical shift is toward continuous privilege governance, because static role assumptions age faster than business access patterns do.

For practitioners

• Tighten authentication on high-value accounts Require phishing-resistant MFA for administrative and sensitive access paths, and remove password-only sign-in wherever a compromise would create broad internal reach.
• Rebuild authorization around actual task scope Compare current entitlements against real job duties, then remove inherited or legacy permissions that no longer map to daily work or approved exceptions.
• Separate emergency access from normal access Keep break-glass access time-bound, monitored, and distinct from routine roles so recovery paths do not become standing privilege by convenience.
• Inventory the accounts that can pivot widely Identify administrator and service accounts with unusually broad reach, then prioritise them for entitlement review before the next access certification cycle.

Key takeaways

• The Deloitte breach demonstrates that authentication weakness and overbroad authorization combine into a single failure path, not two separate problems.
• One compromised administrative account created months of exposure and sensitive data theft, showing how large the blast radius becomes when permissions are excessive.
• The control that would have reduced the damage most directly was tighter privilege design, backed by stronger authentication and cleaner access governance.

Key terms

• Authentication: Authentication is the process of proving that an identity is genuine. In practice, it uses credentials, certificates, biometrics, or other factors to establish who or what is requesting access. For NHIs, the key issue is whether the proof is strong enough to resist theft, replay, or misuse.
• Authorization: Authorization is the decision about what an authenticated identity is allowed to do. In NHI and IAM practice, it covers scope, duration, and allowable actions, and it is the layer that most directly controls blast radius when access is active.
• Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
• Break-glass Access: Break-glass access is an emergency path that bypasses normal access controls when standard authentication fails or a critical incident demands immediate intervention. It must be tightly time-bound, logged, and reviewed, because it exists to restore operations without becoming a permanent back door.

What's in the full article

Opal Security's full article covers the control-level discussion this post intentionally leaves at a higher level:

• The article walks through the authn and authz concepts in plain language, including how they differ and how they work together.
• It expands on password, MFA, biometrics, geolocation, and behavioural authentication as distinct proof methods.
• It describes RBAC, ABAC, DAC, MAC, and emergency access as different authorization models and where each fits.
• It retells the Deloitte breach example with more detail on how weak access control enabled broad compromise.

👉 Opal Security's full article explains the authentication factors, authorization models, and Deloitte breach context in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.