Application identity gaps expose cleartext credentials and IdP bypasses

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Orchid Security's blog post: Cleartext credentials, IdP bypasses, and inconsistent access controls remain common in discovered apps.

Why it matters: It matters because IAM teams cannot govern what they cannot see, and hidden application-level auth flows create persistent identity risk across legacy, acquired, and custom estates.

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.

Context

Application identity posture is the state of authentication paths, credentials, and access controls embedded inside applications, not just the central IAM stack. The problem is that mature identity programmes can still miss app-level behaviour that bypasses the corporate Identity Provider or stores secrets in ways auditors never see.

In large estates, especially where acquisitions and legacy systems are involved, those hidden flows become governance blind spots. Continuous discovery is useful here because the control failure is often not the absence of a policy but the presence of an ungoverned application path that sits outside standard review cycles.

Orchid Security’s article frames this as a visibility and posture problem rather than a pure access-management issue. That distinction matters for practitioners because the remediation target is the application’s embedded identity logic, not just central directory policy.

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. MFA, conditional access, session controls, and revocation can all be weakened or skipped, which leaves the organisation dependent on local application logic that is often inconsistent and harder to govern. The result is fragmented trust and a larger attack surface.

Q: Why do cleartext credentials in applications create such a high breach risk?

A: Cleartext credentials turn application storage into usable access material. If an attacker reaches source code, configuration files, or a mismanaged support system, they may gain immediate authentication capability without needing to break encryption or guess passwords. That shortens the attack path and makes credential discovery a direct path to unauthorised access.

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. The key test is whether the control shows effective privileges and conflict outcomes, not just that the policy exists on paper.

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.

Technical breakdown

Why application-level identity flows bypass central IAM

Applications often embed their own authentication logic, secret handling, and authorization checks. That means a user can authenticate through a corporate IdP for one path while a second path, API, or legacy workflow still accepts a local credential, a hard-coded secret, or a weaker protocol. From an identity governance perspective, the application becomes a parallel trust boundary. Central IAM can issue and federate identity, but it cannot automatically normalize every embedded control inside the code or configuration of each app. In acquired and long-lived systems, this drift accumulates across technology stacks and ownership boundaries.

Practical implication: map application authentication paths separately from central IdP coverage so hidden login routes are not mistaken for governed access.

Cleartext credentials and weak hashing as posture failures

Cleartext storage and weak hashing are not just poor hygiene, they are evidence that the application’s identity design does not assume credential exposure. A stored secret can be copied, reused, or moved laterally without any control point in the central IAM stack noticing the misuse. For NHI and human identity alike, secret protection is part of the effective identity boundary because the credential itself often becomes the access mechanism. When applications store credentials in recoverable form, downstream identity controls such as MFA, session policy, or recertification do not address the root exposure.

Practical implication: treat exposed credential storage as an application identity defect and prioritize it ahead of downstream access-review work.

How inconsistent access control enforcement creates governance gaps

Access control fails when authorization logic is uneven across screens, APIs, and backend functions. One path may enforce role checks while another silently accepts the same request or defaults to permissive access. That creates a fractured control surface where governance evidence exists in policy documents but not in runtime behaviour. In identity security terms, the app is not enforcing the same authorization decision everywhere the identity is used. This is especially common when older protocols, custom code, and organic feature growth coexist in the same environment.

Practical implication: validate authorization at the application path level, not only through policy review or directory-side entitlement models.

Threat narrative

Attacker objective: The attacker seeks access through the weakest embedded application identity path while avoiding the controls enforced by the corporate IdP.

1. Entry begins with a user or attacker reaching an application path that accepts a local credential, a bypassed IdP route, or a weak protocol instead of the governed corporate login flow.
2. Credential access occurs when the application stores secrets in cleartext or weakly hashed form, making reuse and theft straightforward.
3. Escalation follows when inconsistent access control enforcement allows broader app functions or data paths than intended.
4. Impact is the exposure of sensitive application data and the erosion of confidence in centrally managed identity controls.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

IdP coverage does not equal identity control coverage. A corporate Identity Provider can authenticate many users and workloads, yet still leave local credentials, alternate flows, and protocol exceptions untouched. That means the real governance gap is often the difference between authentication policy and application behaviour. The implication is that identity assurance must move from directory-centric reporting to application-path validation.

Cleartext credential storage is a symptom of broken trust boundaries. When an application keeps recoverable secrets, it has already collapsed part of the security model that downstream IAM controls rely on. This is not just a secrets-management issue, because the application itself has encoded unsafe trust into its design. Practitioners should interpret this as evidence that identity controls were never fully implemented inside the application boundary.

Hidden auth flows create identity blind spots after acquisitions and long-lived development cycles. Legacy apps, merged estates, and home-grown workflows often retain control decisions that no one revisits during standard access reviews. Those orphaned routes are exactly where IdP bypasses and weak authorization persist. The practitioner conclusion is clear: governance needs runtime visibility into application behaviour, not just policy attestation.

Application identity posture belongs in the same risk conversation as NHI governance. The same pattern appears whenever a control plane assumes all access passes through one governed path but reality includes local secrets, embedded protocols, and legacy exceptions. That overlap matters because the enterprise identity estate now spans human, non-human, and application-authored flows. Teams should align application posture review with broader identity security programme design.

From our research library:

• 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.
• Read next: Identity Security Posture Management (ISPM) Guide

What this signals

Application identity posture has to be measured where the app actually makes decisions. If the corporate IdP is only one path among several, then policy-based IAM reporting will overstate control maturity. Practitioners should expect the next governance gap to be runtime validation of embedded auth logic, not another directory-side dashboard.

Hidden auth routes are the new exception management problem. Mature IAM programmes already know how to manage accounts and entitlements, but they are less prepared to catalogue alternate login flows, legacy protocols, and application-local secrets. The programme response is to bring application behaviour into the same review cycle as human and NHI access decisions.

Posture discovery now needs to cross the human and NHI boundary. The article shows that application auth drift is not just a human IAM concern, because the same application may also expose service credentials or machine-to-machine paths that bypass the governed path. That makes application identity review a shared control point for identity security teams.

For practitioners

• 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.
• Reassess post-acquisition application identity Treat merged and legacy applications as separate identity boundaries until their authentication, secrets, and authorization behaviour is proven consistent with corporate policy.
• Use continuous posture discovery Refresh identity posture checks continuously rather than relying on annual reviews, because application ownership and control paths change faster than manual audit cycles.

Key takeaways

• Application identity gaps persist when apps retain their own login paths, secret storage, and authorization logic outside central IAM.
• The article’s figures show a mixed posture problem, with cleartext credentials, IdP bypasses, and inconsistent access control all appearing in a meaningful share of applications.
• Practitioners need continuous application-path validation, because discovery alone does not prove that identity controls are actually enforced at runtime.

Key terms

• Application Identity Posture: The state of how an application authenticates, authorises, and stores credentials within its own implementation and surrounding services. In practice, it shows whether identity control lives in governed platforms or is embedded in code, configuration, and local exceptions that security teams must continually discover and manage.
• Identity Provider: An identity provider is the system that authenticates a user or workload and issues the trust signal used by downstream applications. In federated environments, it becomes a high-value control point because compromise, misconfiguration, or over-trust at this layer can affect many services at once.
• Cleartext credentials: Cleartext credentials are usernames, passwords, tokens, or secrets stored in readable form instead of protected by proper secret management. They are dangerous because they can be reused directly by attackers and often outlive the context in which they were created.
• Runtime Authorization: Runtime authorization is the act of checking whether an identity should keep access while it is actively operating, not just when it is created. It matters for agents and automated workloads because their behaviour can change after approval. This makes continuous verification more important than one-time provisioning.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.