App Consent Governance is the control and review of what access users grant to applications and how that access is approved, limited, and revoked. In IAM, it covers consent workflows for OAuth and OIDC apps, enforcing least privilege, periodic recertification, risk checks, and removal of stale permissions.
What App Consent Governance Actually Covers
App consent governance is not just a permission review. It is the policy and control layer that decides which applications may receive delegated access, what scopes they can request, who can approve them, and when that approval must be revisited or removed.
Its purpose is to stop access from accumulating silently. In practice, that means distinguishing low-risk, well-understood integrations from apps that request broad data access, persistent tokens, or permissions that exceed the business need.
Why Consent Becomes a Governance Problem
Consent is powerful because it can translate a single user action into durable access across mail, files, profiles, messages, or directory data. That makes it attractive to attackers and risky for organisations when users can approve apps without effective oversight.
Governance matters most when the approval path is fragmented, when users can self-authorise high-impact scopes, or when admins cannot see which apps already hold access. The underlying problem is usually not the app itself, but the trust decision attached to it.
For organisations that use Microsoft ecosystems, NHIMG’s Entra ID Applications and Consent Guide is a direct companion for understanding consent policies, admin consent workflows, and the practical abuse patterns around risky OAuth apps.
What Good Consent Governance Controls
Strong consent governance usually combines approval policy, scope limitation, visibility, and periodic review. The aim is to ensure that an app only receives the permissions it genuinely needs, that high-risk consent is routed through stronger review, and that old grants do not linger after the business need ends.
This is also where least privilege becomes operational. Apps should not receive broad delegated permissions when a narrow permission set will work, and granted access should be revalidated after changes in ownership, vendor status, or application purpose.
Where organisations need a broader lifecycle view, NHIMG’s SaaS-to-SaaS and OAuth App Governance Guide helps connect consent decisions to token risk, revocation, and integration lifecycle management.
How To Recognise Consent Drift
Consent drift happens when the app grant no longer matches the current risk posture. A once-trusted integration may become overprivileged after expansion, ownership change, or vendor compromise, while orphaned grants can remain active long after the app is no longer needed.
That drift is difficult to see without inventory and review. Organisations need a reliable view of which apps exist, what scopes they hold, who approved them, and whether the approval still maps to a current business purpose.
For a broader identity lens that includes where people and machine access meet, NHIMG’s Human vs Non-Human Identity helps explain why consent, delegated access, and shared access patterns deserve joint governance.
Risk and Threat Considerations
App consent is a common attack path because it can turn a convincing prompt or malicious integration into authorized access without stealing a password. Consent phishing, overbroad scopes, and stale grants can give attackers durable access to mail, files, directory data, and downstream SaaS services.
Failure mechanism: Users or admins approve an app that requests more access than the business requires, or they fail to remove a grant after the app is no longer trusted. That creates a persistent authorization path that can survive beyond the initial approval event.
Impact: The result can be data exposure, mailbox or file access, lateral movement into connected services, and a delayed breach signal because the access appears to be legitimate consent rather than obvious intrusion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | App consent governance controls which app access is approved, reviewed, and revoked. |
| AC-6 — Least Privilege | Consent scopes should be limited to the minimum access an app needs. | |
| IA-5 — Authenticator Management | OAuth tokens and related secret material depend on lifecycle control and revocation. | |
| Recommendation — Review and remove app grants under account management oversight. Limit consented app permissions to the minimum required scope. Manage issued tokens and related secrets so stale access is revoked promptly. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | App consent is an access-control decision over third-party application permissions. |
| Recommendation — Define and enforce access rules for application consent and revocation. | ||
Practitioner Guidance
Why practitioners should care: Consent decisions are effectively access-control decisions, so they should be owned and reviewed like any other privileged trust relationship. Treat high-impact scopes, third-party publishers, and long-lived grants as governance items, not just user convenience features.
What to watch for: Repeated user-consent prompts, unfamiliar apps requesting broad scopes, unreviewed admin consent, and grants that outlive the app’s business purpose. Those are usually the clearest signals that the consent model is drifting away from control.
Practitioner takeaway: The healthiest consent program is one that makes approval narrow, visible, reviewable, and reversible.