A blocked app is a third-party application that is denied access because it does not meet policy or security requirements. Blocking prevents the app from using approved OAuth access, which reduces exposure from untrusted integrations, excessive permissions, or applications that no longer have a valid business need.
Expanded Definition
A blocked app is a third-party application that has been explicitly denied access to an environment, tenant, or API because it fails policy, trust, or security requirements. In NHI governance, the decision is usually based on OAuth consent risk, excessive requested scopes, weak publisher assurance, or a business approval that has expired. This is different from a suspended user session or a revoked token: blocking targets the application itself, not just a single credential or login event.
Definitions vary across vendors on whether “blocked” means permanently disallowed, temporarily quarantined, or simply prevented from receiving new consent. In practice, organisations treat blocked apps as part of application access governance, software supply chain review, and Zero Trust enforcement. A useful reference point is the NIST Cybersecurity Framework 2.0, which emphasises access control, risk management, and continuous monitoring for connected systems.
The most common misapplication is treating a blocked app as a one-time admin cleanup, which occurs when teams do not connect the block decision to ongoing consent review and token revocation.
Examples and Use Cases
Implementing blocked-app controls rigorously often introduces friction for legitimate integrations, requiring organisations to weigh user productivity against the cost of accepting unreviewed access paths.
- A marketing SaaS app requests broad mailbox and directory scopes, but security blocks it until the publisher, data handling, and scope minimisation are reviewed.
- An AI productivity tool is denied OAuth consent because it requests persistent access to files and messages that exceeds its stated business need.
- A legacy integration is blocked after ownership changes and no valid business sponsor can be identified during review.
- A partner application is temporarily blocked while the organisation validates its security posture, then reapproved with narrower permissions.
- A cloud tenant blocks risky apps identified through discovery because they create unmanaged NHI exposure and token sprawl, a pattern highlighted in the Ultimate Guide to NHIs.
Blocking is usually paired with app inventory, consent governance, and conditional access rather than used as an isolated control. In standards terms, it aligns well with the access governance concepts in NIST Cybersecurity Framework 2.0 and with identity assurance practices that limit what an application can do after consent is granted.
Why It Matters in NHI Security
Blocked apps matter because third-party integrations often become the easiest route into sensitive data, especially when they retain OAuth grants long after the original need disappears. NHIMG research shows that 92% of organisations expose NHIs to third parties, raising supply chain risk, and 97% of NHIs carry excessive privileges, which makes uncontrolled app access especially dangerous. The Ultimate Guide to NHIs also reports that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a strong signal that blocked-app governance is often incomplete.
From a security perspective, blocked apps help reduce secret exposure, token misuse, and lateral movement through trusted integrations. They are especially important when organisations are adopting Zero Trust principles and need to prove that every app connection remains justified, scoped, and monitored. That makes blocked-app policy a practical control for tenant hygiene, incident containment, and least-privilege enforcement. Organisations typically encounter the real cost of a blocked app only after a compromised integration is found exfiltrating data, at which point the need to revoke access at the application level becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Blocked apps reduce risky third-party NHI exposure and unapproved OAuth access. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions for connected apps are governed through least-privilege control. |
| NIST Zero Trust (SP 800-207) | 5.2 | Zero Trust requires every app request to be explicitly authorized and continuously validated. |
| NIST SP 800-63 | AAL2 | App access decisions should reflect assurance and risk appropriate to the protected resource. |
| OWASP Agentic AI Top 10 | A07 | Agentic and AI apps can abuse broad tool access if not blocked or constrained. |
Block autonomous apps that request unnecessary tools, scopes, or persistent access.
Related resources from NHI Mgmt Group
- How should organisations troubleshoot admin policy enforcement errors when a third-party app is blocked in Google Workspace?
- Who is accountable when a blocked or misconfigured OAuth app disrupts access to business systems?
- Why can a single SaaS app create such a large blast radius?
- What is the difference between a service account and an OAuth-connected app?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
