A shadow app is an OAuth or GitHub App that exists in the environment without clear ownership or active oversight. These integrations are risky because they can retain broad permissions quietly, making it hard to judge whether the access is still needed or still appropriate.
Expanded Definition
Shadow apps are integrations created through OAuth consent, GitHub App installation, or similar delegated authorization paths that persist without a clear business owner, documented purpose, or active lifecycle oversight. In NHI practice, they sit alongside service accounts and API tokens as non-human identities that can silently retain access after the original project has ended. Definitions vary across vendors on whether a shadow app must be fully unknown to security or merely ungoverned, but the operational risk is the same: permissions outlive accountability.
Unlike a well-managed integration, a shadow app often bypasses normal onboarding, approval, and offboarding controls. That makes it especially important to connect this term to governance models such as NIST Cybersecurity Framework 2.0, which emphasizes identifying assets, controlling access, and monitoring for misuse. The Ultimate Guide to NHIs frames this as a visibility and remediation problem, not just an application inventory issue.
The most common misapplication is treating a shadow app as a harmless “one-off” integration when it actually has broad, persistent permissions and no accountable owner.
Examples and Use Cases
Implementing shadow app detection rigorously often introduces inventory friction, requiring organisations to weigh fast self-service integrations against the cost of ongoing review and access revalidation.
- A developer authorizes a GitHub App for code scanning, then leaves the team while the app keeps repository write permissions and webhook access.
- A marketing team installs an OAuth app for campaign automation, but no central register records who approved it or which data scopes it can still read.
- A third-party support tool is connected to a SaaS tenant during an incident and never removed, leaving dormant access to tickets and attachments.
- A CI/CD integration is approved by one project lead, yet the underlying credentials survive after the pipeline is retired, creating an orphaned NHI.
These cases are easier to spot when organisations apply identity governance patterns from Ultimate Guide to NHIs and align them with access review practices described in NIST Cybersecurity Framework 2.0. The key question is not whether the app was once useful, but whether it still has a valid owner, purpose, and scope.
Why It Matters in NHI Security
Shadow apps matter because they turn normal delegation into silent privilege accumulation. Once an app is installed, it can continue acting on behalf of a user, team, or repository even after the original context changes. That creates hidden attack paths, weakens segregation of duties, and complicates revocation when incidents occur. This is why the Ultimate Guide to NHIs treats visibility and offboarding as core controls rather than optional hygiene. It also aligns with NIST Cybersecurity Framework 2.0 principles around governance, continuous monitoring, and access management.
NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, a useful warning sign for shadow app management because both problems depend on knowing what exists before you can secure it. In practice, a shadow app may keep broad permissions quietly, making it hard to prove whether access is still needed or appropriate.
Organisations typically encounter the impact only after a breach review, token audit, or compliance failure reveals that an unowned integration was still active, at which point shadow app cleanup 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 address the attack and risk surface, while 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers discovery and governance gaps for unmanaged non-human identities like shadow apps. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and access review expectations apply directly to shadow app permissions. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of non-human access, including installed apps. |
Inventory every integration, assign an owner, and revoke any app without a valid business purpose.
