Notifications
Clear all
Topic starter
15/08/2026 6:08 pm
TL;DR: Application sprawl, hardcoded credentials, weak authorization visibility, and ungoverned AI agents leave identity teams blind to where real enforcement happens, according to Orchid Security. The practical problem is not directory coverage but application-level identity behaviour that conventional IAM, IGA, and SSO reporting still cannot reliably prove or control.
NHIMG editorial — based on content published by Orchid Security: application identity dark matter and hidden enforcement gaps
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.
Questions worth separating out
Q: How should security teams govern hidden identities inside application estates?
A: Start by inventorying every application that issues or consumes identity, then map where authentication and authorisation actually occur.
Q: Why do application-side authorization paths undermine least privilege?
A: Because least privilege can only be proven where access is actually enforced.
Q: What breaks when machine credentials are not rotated?
A: When machine credentials are not rotated, stale access accumulates and the organisation loses confidence that the secret still reflects the intended scope.
Practitioner guidance
- Build an application identity inventory Document every application that authenticates users or workloads, including custom apps, legacy tools, and disconnected systems.
- Find and eliminate embedded credentials Scan code repositories, deployment scripts, configuration files, and binaries for hardcoded passwords, API keys, and service account secrets.
- Test enforcement at the application layer Validate whether applications actually honour MFA, SSO, and role restrictions by exercising fallback paths, local admin accounts, and legacy authentication routes in controlled testing.
What's in the full article
Orchid Security's full blog covers the operational detail this post intentionally leaves for the source:
- How to map application-side authentication paths, including local accounts and legacy fallback routes
- How to find embedded credentials in code, scripts, binaries, and deployment artefacts
- How to validate whether MFA, SSO, and authorization policies are actually enforced inside the application
- How to build audit evidence from application behaviour rather than directory exports
👉 Read Orchid Security's analysis of application identity dark matter and hidden enforcement paths →
Identity dark matter in applications: what IAM teams are missing?
Explore further
15/08/2026 6:16 pm
Identity dark matter is now an enterprise control problem, not just a discovery problem. Directory completeness does not equal application governance, because real access decisions often happen inside the application layer. That means IAM programmes that stop at SSO, IGA, or provisioning coverage are measuring the wrong surface. The practitioner conclusion is that identity estate mapping must include enforcement paths, not just assigned entitlements.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Only 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the same guide.
A question worth separating out:
Q: Who should be accountable when an AI agent or service account causes access drift?
A: The accountable party should be the human or team that authorised the identity and owns the business process behind it. The agent cannot own its own lifecycle in a governance sense. Accountability must stay with a human owner who can approve, revoke, or re-scope access when usage changes.
👉 Read our full editorial: Application identity dark matter is the real IAM control gap
