TL;DR: Authentication and authorization are the two core controls that determine who a system accepts and what that identity can do, and Opal Security uses a Deloitte breach to show how weak password-only access and overbroad permissions can cascade into enterprise-wide compromise. The lesson is that IAM programmes fail when verification and privilege governance are treated as separate problems instead of one control plane.
At a glance
What this is: This is an explainer on authentication and authorization in IAM, with a breach example showing how weak verification and excessive privilege combine into broad compromise.
Why it matters: It matters because IAM teams still have to govern human, machine, and emerging autonomous access with controls that verify identity and constrain privilege at the same time.
👉 Read Opal Security's analysis of authn, authz, and IAM failure modes
Context
Authentication and authorization are the two basic IAM decisions every access flow depends on: first the system verifies the subject, then it decides what that subject can do. The article argues that these controls only work when they are treated as linked governance problems, not separate technical steps, because weak verification and loose entitlements amplify one another.
For IAM and PAM teams, the practical issue is not whether these concepts are familiar, but whether their implementation still matches how access is actually granted in modern environments. As identities expand across users, service accounts, and automated workflows, the gap between authentication confidence and authorization scope becomes the place where programmes most often fail.
Key questions
Q: How should security teams balance authentication strength and authorization scope?
A: Security teams should treat authentication and authorization as one decision chain. Strong sign-in controls reduce impersonation risk, but they do not compensate for broad entitlements. The goal is to ensure that a validated identity can only reach the minimum set of resources needed for the task, with higher-risk access requiring stronger proof and tighter review.
Q: Why do privileged accounts create such large breach impact?
A: Privileged accounts often sit at the intersection of identity, administration, and internal connectivity. If one of those accounts is compromised, the attacker does not just get a login, they inherit the scope of the role. When authorization is broad, a single weak authentication event can become a path into systems, data, and control planes.
Q: What do security teams get wrong about MFA and access control?
A: Teams often assume MFA solves the access problem by itself. In reality, MFA only strengthens the front door. If the authenticated identity still has excessive permissions, shared admin duties, or poor lifecycle governance, the attacker can still move freely after login. Access control has to reduce reach, not just raise the bar at entry.
Q: Who is accountable when an overprivileged account is compromised?
A: Accountability usually spans identity owners, application owners, and security governance because the failure is rarely one control alone. The organisation must decide who approves privilege, who reviews it, and who is responsible when a role outlives its business need. That ownership should be explicit for every privileged account class.
Technical breakdown
Authentication factors and why password-only access breaks down
Authentication verifies that an identity is genuine by checking one or more proof factors such as a password, token, hardware key, biometric, location, or behavioural signal. Password-only access is brittle because compromise of a single secret often becomes full impersonation. Stronger factors reduce phishing exposure and make remote takeover harder, but they still need to be matched to the risk of the protected asset and the attack path most likely to be used.
Practical implication: replace single-factor access on high-value systems with phishing-resistant authentication and review which accounts still rely on reusable secrets.
Authorization models and how excess privilege becomes lateral movement
Authorization answers a different question: once identity is accepted, what can it reach? RBAC, ABAC, discretionary controls, and emergency access all encode different assumptions about how access should be bounded. The article’s breach example shows the danger of an identity whose permissions are far broader than its job function, because privileged accounts turn one compromised login into a path across systems, data, and administrative functions.
Practical implication: map high-risk accounts to minimum necessary access and look for entitlements that exist only because they were convenient to assign.
Why verification and privilege governance have to work as one control plane
Modern IAM fails when authentication is treated as a gate and authorization is treated as a separate downstream checklist. In practice, the value of strong authn drops sharply if the authenticated identity is still allowed to reach far more than it should, and the value of tight authz drops if the verifier cannot distinguish a legitimate actor from an attacker using stolen credentials. That coupling is what makes continuous access decisions, contextual policies, and just-in-time access so relevant.
Practical implication: evaluate IAM by the combined outcome of proof strength and entitlement scope, not by MFA adoption or role design alone.
Threat narrative
Attacker objective: The objective was to turn one weakly protected identity into broad internal access and sustained data theft across the enterprise.
- Entry occurred when attackers compromised a single email administrator account protected only by a password, giving them an initial authenticated foothold.
- Escalation followed because the compromised account had unrestricted or overly broad authorization, allowing the attackers to move toward more valuable internal targets.
- Impact accumulated over months as attackers allegedly stole sensitive email, credentials, architecture diagrams, IP addresses, and other internal information from the environment.
Breaches seen in the wild
- DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
- Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Authentication and authorization are no longer separable IAM disciplines. The article’s core lesson is that identity proof and privilege scope now fail together, because an attacker who crosses the first gate often inherits the second one too. That means IAM programmes must be judged on the combined strength of verification and authorization, not on MFA coverage or role design in isolation. Practitioners should treat the two controls as one continuous governance decision.
Broad administrative access creates an identity blast radius, not just a privilege problem. The Deloitte example shows that a single over-entitled mailbox administrator can expose a much larger security surface than the role name suggests. The real failure mode is not only weak authentication, but the assumption that one account can safely bridge routine operations and deep network reach. Practitioners should assume every privileged account is a potential lateral movement hub until proven otherwise.
Conditional access controls only matter if they change the attack path. Behavioural, contextual, and step-up controls are useful when they alter what a stolen identity can do after authentication succeeds. If they are layered on top of unchanged authorization sprawl, they become inspection without containment. Practitioners should measure whether control combinations reduce reach, shorten dwell time, or merely add friction.
Continuous access decisions are the next logical step for identity governance. Static approval at sign-in does not match how modern access is actually used, especially when administrative identities can be abused long after initial authentication. The governance question is not whether users or systems can log in, but whether their effective privilege remains justified throughout the session. Practitioners should move from one-time admission logic to ongoing authorization review.
Authn failures become IAM failures when entitlement design is treated as secondary. The breach illustrates that identity assurance without entitlements discipline gives defenders a false sense of control. The discipline must extend across account lifecycle, admin scope, emergency access, and traceability. Practitioners should align authentication strength with authorization minimisation as a single programme outcome.
From our research:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- Another finding from the same research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility.
- For practitioners building a broader NHI programme, the Ultimate Guide to NHIs , The NHI Market is the next step for understanding the tooling landscape.
What this signals
Credential strength and entitlement scope now need to be managed as one governance surface. Teams that separate sign-in assurance from privilege control will keep missing the real risk, because attackers exploit the gap between them. In a broader identity programme, that means the same access review and admin scoping discipline should cover both human administrators and machine-like privileged identities.
Identity blast radius is the better planning concept than account count. A programme can have strong authentication adoption and still fail if a handful of privileged identities can traverse too much of the environment. That is the signal to watch: not how many identities exist, but how much damage one valid login can still cause.
With 88.5% of organisations acknowledging their NHI IAM practices lag behind or only match human IAM, according to the 2024 Non-Human Identity Security Report, the gap is no longer about awareness alone. Teams need access governance that scales from human admins to non-human workload identities before privilege sprawl becomes the default operating model.
For practitioners
- Strengthen privileged authentication Require phishing-resistant factors for all administrative and high-value accounts, and remove password-only access wherever a compromise would expose internal systems or data. Prioritise accounts that can reach mail, identity, infrastructure, and security tooling.
- Reduce administrative blast radius Rebuild privileged roles so no single administrator account can reach broad internal assets by default. Split duties, narrow admin scopes, and verify that emergency access is truly exceptional rather than a standing workaround.
- Tie authorization to job function Review whether role assignments reflect current operational need or historical convenience. Remove inherited access, tighten default entitlements, and use attributes or conditions only where they actually change reach in a meaningful way.
- Instrument for suspicious post-authentication behaviour Alert on access patterns that do not match the expected function of the account, especially mailbox admins and other privileged identities that begin touching architecture data, credential stores, or sensitive directories outside normal work.
Key takeaways
- Authentication answers whether an identity is real, but authorization decides how far that identity can go.
- A single compromised privileged account can produce enterprise-wide impact when the role has excessive reach.
- IAM programmes should be measured by combined proof strength and privilege minimisation, not by MFA or RBAC in isolation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Identity proof and access management are central to the article's authn discussion. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and entitlement scoping are the core authz control concerns here. |
| NIST Zero Trust (SP 800-207) | Continuous verification and explicit authorization align with the article's core IAM argument. |
Require strong authentication for privileged accounts and review whether proof strength matches access risk.
Key terms
- Authentication: Authentication is the process of proving that an identity is real before a system grants access. In practice, it can involve passwords, tokens, hardware keys, biometrics, or contextual signals. Strong authentication reduces impersonation risk, but it does not limit what a validated identity can do afterward.
- Authorization: Authorization is the decision about what an authenticated identity may access or change. It translates policy into actual reach across applications, data, and infrastructure. Weak authorization creates excessive privilege, which means a valid login can still become a broad compromise path.
- Privileged account: A privileged account is an identity with elevated administrative or control-plane access beyond ordinary user permissions. These accounts are powerful because they can alter systems, data, or other identities. If they are poorly scoped, one compromise can expose far more than the account’s name implies.
- Identity blast radius: Identity blast radius is the amount of damage a compromised identity can cause before containment. It depends on authentication strength, entitlement scope, and how quickly abnormal activity is detected. The concept is useful because it measures practical exposure rather than just counting accounts or policies.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.
This post draws on content published by Opal Security: Authn and Authz: Two Sides of the IAM Coin. Read the original.
Published by the NHIMG editorial team on 2024-04-30.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org