Notifications
Clear all
Topic starter
24/06/2026 11:10 pm
TL;DR: Shadow access forms when approved SaaS and cloud applications receive untracked roles, tokens, and emergency permissions outside IAM or IGA workflows, creating blind spots that weaken least privilege and auditability, according to SecurEnds. The real problem is not shadow IT but governance drift inside sanctioned systems, where access outlives the work that justified it.
NHIMG editorial — based on content published by SecurEnds: shadow access in cloud and SaaS environments
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
Questions worth separating out
Q: How should security teams detect shadow access in SaaS and cloud apps?
A: Start by discovering app-level roles, direct assignments, API tokens, nested groups, and emergency privileges, then compare them with central IAM and IGA records.
Q: Why does shadow access create a bigger risk than simple overprovisioning?
A: Overprovisioning can still be visible in central identity tools, but shadow access often sits outside them.
Q: What do organisations get wrong about temporary access in SaaS platforms?
A: They treat temporary access as self-expiring when it usually depends on someone remembering to revoke it.
Practitioner guidance
- Extend certification to app-native entitlements Include SaaS roles, inherited permissions, API tokens, and service accounts in access reviews so the review scope matches where privileges are actually granted.
- Eliminate unowned temporary access Require every project role, emergency grant, and token to have an owner, an expiry, and a documented cleanup path before it is approved.
- Normalize role meaning across platforms Build a translation layer for role names and bundled permissions so reviewers can compare what admin or contributor means in each SaaS application.
What's in the full article
SecurEnds' full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how shadow access appears inside SaaS consoles and cloud apps.
- Expanded discussion of real-world scenarios such as direct admin grants, OAuth scope creep, and emergency access.
- Practical detection patterns for identifying app-native entitlements that central IAM workflows miss.
- Implementation detail on how SecurEnds connects entitlement discovery to certification and remediation.
👉 Read SecurEnds' analysis of shadow access in cloud and SaaS environments →
Shadow access in SaaS and cloud apps: what teams miss?
Explore further
25/06/2026 7:53 am
Shadow access is a governance failure, not an IT nuisance. The article describes sanctioned systems accumulating unsanctioned permissions, which means the break is inside the identity process itself, not outside it. IAM tools that only see directory state cannot explain app-native roles, API tokens, or local admin grants. The practical conclusion is that access governance must follow where the entitlement is actually created.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: How do identity teams govern direct role changes made inside applications?
A: They need to reconcile in-app changes back into the identity source of record and require those changes to appear in certification, audit, and remediation workflows. If app-native assignments remain outside governance, the organisation is managing only the directory, not the real access model.
👉 Read our full editorial: Shadow access in cloud apps: the governance gap IAM misses
