Who is accountable when authorization phishing succeeds in an enterprise identity stack?

Why This Matters for Security Teams

Authorization phishing is not just a user-awareness problem. It is an identity governance failure that turns a legitimate consent or OAuth flow into a trusted path for token theft, app abuse, or hidden persistence. When an attacker convinces a user or admin to approve access, the damage often reflects gaps in app registration review, consent policy, browser-layer detection, and exception handling, not only a single bad click.

That is why accountability usually extends beyond the person who approved the prompt. Identity operations, security engineering, and the business owner who accepted the exception all share responsibility for the control environment that allowed the approval to succeed. NHI Mgmt Group research on Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which helps explain why one successful authorization event can create outsized impact.

Practitioners should also treat this as a governance issue under established control families such as NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access approval, monitoring, and review are left informal. In practice, many security teams encounter accountability disputes only after a malicious app has already obtained durable access and begun moving data or issuing downstream API calls.

How It Works in Practice

The practical question is not only who clicked approve, but who owned each layer of control around the approval path. In a mature enterprise, accountability is distributed across the identity team that defines consent policy, the security team that detects risky OAuth patterns, the platform team that governs app registration and API scopes, and the business owner who requested or tolerated the exception.

That distribution matters because authorization phishing often succeeds through legitimate mechanisms. A user may be tricked into granting delegated access, a developer may accept an overbroad device code flow, or an admin may approve a third-party app that looks operationally necessary. When those approvals are not time-bound, reviewed, or constrained by policy, the resulting access can outlive the original business need.

• Identity teams should define which apps may request sensitive scopes and which approval paths require admin review.
• Security teams should monitor for impossible consent patterns, unusual app lineage, and token use after consent.
• Business owners should approve only the minimum access needed and should document why an exception exists.
• Governing bodies should ensure report-only detections are not treated as controls if no enforcement follows.

For NHI-heavy environments, the blast radius is larger because the approved app often becomes a machine-to-machine bridge into secrets, APIs, and service accounts. The 52 NHI Breaches Analysis and Top 10 NHI Issues both underscore the pattern: once identity trust is extended, downstream access often becomes the real compromise path. These controls tend to break down in hybrid identity stacks with legacy consent models and loosely governed developer tooling because approvals, tokens, and exceptions are owned by different teams with no single decision record.

Common Variations and Edge Cases

Tighter consent governance often increases friction for developers and application owners, so organisations have to balance faster onboarding against stricter approval discipline. That tradeoff is real, but guidance suggests it should be handled through policy design rather than informal exceptions.

There is no universal standard for exactly where accountability stops in every enterprise, especially when SaaS vendors, delegated admins, and shadow IT apps are involved. In some organisations, the line sits with the identity operations team because they own consent policy and tenant configuration. In others, accountability shifts to the business unit when it requests a broad exception and accepts the risk. The key is that the approval chain must be explicit.

One common edge case is report-only detection. If a team enables alerts but never enforces blocking or review, accountability for the resulting exposure cannot be assigned to tooling alone. Another is service-to-service access granted through delegated user consent, where the business justification may seem narrow but the technical reach is broad. Current guidance suggests these decisions should be backed by periodic access review, clear ownership of exceptions, and rapid revocation when the approved purpose changes.

Where that breaks down most often is in environments that mix modern OAuth apps with older directory controls, because no single team can see the full consent, token, and privilege chain in time to intervene.

Related resources from NHI Mgmt Group

• Who is accountable when an agent acts without an organization-scoped session or with insufficient authorization boundaries?
• When does a machine identity become a compliance problem?
• Why is it important to integrate identity and data governance?
• When does secret exposure become a broader identity risk?