Topic starter
16/09/2026 9:21 am
TL;DR: 48% of applications store credentials in cleartext, 44% use authentication paths that bypass the corporate IdP, and 37% fail to enforce access controls consistently, according to Orchid Security, underscoring how legacy and acquired apps keep identity risk hidden. The real issue is not discovery alone but proving which application-level identity flows still sit outside governed IAM boundaries.
Editorial analysis by NHI Mgmt Group, based on content published by Orchid Security: “Al Readiness Checklist”.
By the numbers:
- 48% of applications store credentials in cleartext.
- 44% of applications use authentication paths that bypass the corporate Identity Provider.
- 37% of applications failed to enforce access controls consistently or at all.
Key questions
Q: What breaks when applications bypass the corporate Identity Provider?
A: When applications bypass the corporate Identity Provider, central IAM policies stop being the enforcement point.
Q: Why do cleartext credentials in applications create such a high breach risk?
A: Cleartext credentials turn application storage into usable access material.
Q: How should security teams prove that access policy is actually enforced?
A: They should require evidence that each request was checked against policy rules, reviewed with the right context and either approved, denied or remediated in a traceable workflow.
Practitioner guidance
- Inventory application authentication paths Document every login, token exchange, and alternate access route for critical applications, including any local authentication that bypasses the corporate Identity Provider.
- Prioritize cleartext credential remediation Find applications that store credentials in cleartext or weak hashes and move them to protected secret handling before investing in broader access recertification.
- Validate authorization at runtime Test whether access controls are enforced consistently across UI paths, APIs, and backend functions, then compare the results to the published entitlement model.
Bottom line: Application identity gaps persist when apps retain their own login paths, secret storage, and authorization logic outside central IAM.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
16/09/2026 9:21 am
Application identity posture is now a governance problem, not a discovery problem. The central issue is no longer whether organisations can find applications, but whether they can prove which login paths, credential stores, and authorization checks those applications actually enforce. Once an app carries its own identity logic, it creates a parallel control plane that can sit outside IAM assumptions. Practitioners should treat application identity as part of the governed identity estate, not a separate technical detail.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How should teams govern identity risk in acquired or legacy applications?
A: Treat those applications as separate identity domains until their authentication routes, credential storage, and authorization checks are verified. Acquired and long-lived systems often preserve exceptions that central IAM never sees, so the governance model has to start with discovery, mapping, and control validation inside the app itself.
👉 Read our full editorial: Application identity gaps expose cleartext credentials and IdP bypasses