Identity control gaps in applications expose hidden access paths

At a glance

What this is: This is an analysis of application identity control gaps, showing that hard-coded credentials, IdP bypass paths, weak baseline controls, and outdated authentication protocols remain common across application estates.

Why it matters: It matters because IAM teams cannot govern what they cannot see, and application-level identity flows often determine whether humans, service accounts, and tokens remain inside policy boundaries.

By the numbers:

• 48% of applications store credentials in cleartext.
• 44% of applications have authentication paths that bypass the corporate Identity Provider (IdP).
• 37% of applications failed to enforce access controls consistently or at all.

👉 Read Orchid Security's analysis of application identity control gaps

Context

Application identity security depends on more than login policy. When apps carry their own credentials, alternate authentication paths, or incomplete access control enforcement, central IAM no longer defines the real trust boundary for the environment. That creates a governance gap across human access, service accounts, and other non-human identities.

This Orchid Security analysis focuses on how identity controls fragment across large and changing application estates, especially where acquisitions, legacy builds, or inconsistent development practices have left multiple authentication patterns in place. The core issue is not simply weak configuration, but hidden identity flows that conventional reviews often miss.

For practitioners, the problem is operational as much as architectural. If discovery does not reveal where authentication is handled, where credentials are stored, and where controls are bypassed, then IAM, IGA, and PAM teams are making decisions without a complete identity map.

Key questions

Q: How should security teams map application identity flows across legacy and modern systems?

A: Start by inventorying every authentication path, including local logins, federated login, service-to-service calls, and any exception routes that bypass central IAM. Then verify where credentials are stored, who owns rotation, and whether the application actually enforces the intended control. If you cannot trace a path end to end, you do not have governance over it.

Q: Why do IdP bypass paths create governance risk for IAM programmes?

A: Because they create a second authentication regime outside the controls that IAM teams expect to own. That weakens MFA, logging, conditional access, and lifecycle oversight at the same time. The main risk is not just user convenience, but the loss of a single authoritative identity policy across the estate.

Q: What breaks when applications store credentials in cleartext or weak hashes?

A: Rotation, revocation, and accountability become fragmented because the secret is no longer governed as a managed identity asset. A credential embedded in code or configuration is harder to find, harder to expire, and easier to reuse across environments. The result is a persistent access path that central controls may never fully remove.

Q: Who is accountable when application authentication bypasses the corporate Identity Provider?

A: The application owner, the platform team, and the IAM function all share accountability, but only if the bypass is documented and assigned. If no owner can explain why the exception exists and when it will be removed, the organisation should treat it as an unmanaged identity risk with no clear control boundary.

Technical breakdown

Hard-coded credentials create an identity control shadow

When applications store cleartext or weakly hashed credentials, the application itself becomes a secret holder rather than a policy consumer. That breaks central lifecycle assumptions because rotation, revocation, and audit controls no longer sit in one governed plane. It also makes credential exposure harder to detect, because the secret may live in code, configuration, or embedded runtime logic rather than in a managed vault. In practice, this creates a long-lived control shadow around the application estate.

Practical implication: inventory where application credentials live, then remove any secret that cannot be rotated and revoked centrally.

Identity Provider bypass paths fragment authentication governance

An authentication path that bypasses the corporate Identity Provider creates a second trust model inside the same estate. Users or workloads can authenticate outside standard policy, which means MFA, conditional access, logging, and federation controls may not apply consistently. These paths often emerge in legacy integrations, shadow application logic, or exceptions added for speed and then forgotten. Once bypass routes exist, the organisation no longer has a single authoritative authentication layer.

Practical implication: trace every application login flow back to the authoritative IdP and eliminate unauthorised alternate paths.

Inconsistent access control enforcement turns policy into a partial control

Access control only works when it is enforced at the decision point where the application authorises an action. If controls are missing, partial, or inconsistently applied, then role definitions and entitlement reviews become weaker than they appear on paper. This is especially dangerous in estates with multiple development eras, because older applications may still rely on local logic that predates modern IAM patterns. The result is a governance mismatch between documented policy and real enforcement.

Practical implication: validate access enforcement at the application layer, not only at the identity layer, before certifying entitlements.

Threat narrative

Attacker objective: The attacker wants to reach sensitive systems and data through identity paths that were never fully brought under central control.

1. Entry occurs through exposed credentials, alternate authentication paths, or outdated protocols that let an attacker reach applications outside the normal identity boundary.
2. Escalation follows when the attacker uses bypassed or inconsistently enforced access controls to move from a single foothold into broader application and data access.
3. Impact is achieved through credential reuse, unauthorised access, and the exposure of sensitive application data that central IAM never fully governed.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Application identity security is now a control-plane problem, not a login problem. When nearly half of applications still store credentials in cleartext and many bypass the corporate Identity Provider, the true trust boundary has shifted into the application estate itself. IAM cannot govern a pathway it does not discover, and that makes application-level identity flow mapping a prerequisite for credible assurance.

Identity Provider bypass creates parallel governance that access reviews will not fix. A bypass path is not just a technical exception. It is a second authentication regime with different logging, different policy enforcement, and often different ownership, which means certification and recertification processes can approve access that was never truly under central control. Practitioners should treat every bypass route as an unmanaged identity domain, not a temporary workaround.

Credential storage outside managed secrets systems is an NHI governance failure even when the source article frames it as application hygiene. A hard-coded credential is still a non-human identity control problem because it carries lifecycle, rotation, and revocation obligations. The practical consequence is that NHI governance must extend into application build, deployment, and runtime evidence, not stop at directory-based entitlement review.

Discovery is the differentiator between theoretical posture and actual posture. Continuous, telemetry-driven visibility is what exposes hidden identity paths across legacy, acquired, and rapidly changing applications. Without that level of inventory, organisations overestimate the coverage of IAM, underestimate the number of identities in use, and miss the places where stale controls persist.

Hidden identity flows are the real attack surface in heterogeneous estates. The most exposed applications are often not the newest ones, but the ones with accumulated exceptions, legacy authentication, and undocumented local controls. That means security leaders should measure identity risk by flow complexity and enforcement gaps, not by application count alone.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why hidden application identity paths remain difficult to govern.
• For a broader view of lifecycle and offboarding failure modes, see 52 NHI Breaches Analysis.

What this signals

Application identity programmes now need to be run as discovery-first control programmes, not policy-first exercises. If the environment contains bypass paths and embedded credentials, recertification alone will keep certifying incomplete truth. The practical shift is to treat every new application and acquired estate as an identity inventory problem before it becomes an access review problem.

Identity flow drift: when authentication paths diverge from the corporate IdP, your control plane and your real estate stop matching. That gap will widen in estates with legacy systems, mergers, and custom integrations unless discovery is continuous and exception handling is time-boxed.

The next maturity step is to connect application discovery with secrets hygiene and control validation in one operating model. That aligns the work of IAM, IGA, and PAM teams around the same evidence set instead of three separate views of access.

For practitioners

• Map every application authentication path Trace each login, token exchange, and service-to-service credential path back to the authoritative identity control point. Flag any route that does not pass through the corporate Identity Provider or a documented exception process.
• Remove hard-coded credentials from code and config Search source repositories, deployment manifests, and runtime configuration for cleartext credentials or weak hashing patterns. Replace them with centrally managed secrets and define a rotation and revocation owner for each application.
• Revalidate access controls at the application layer Do not rely on directory roles alone. Test whether the application actually enforces access decisions for sensitive functions, especially in legacy systems, acquired applications, and custom integrations.
• Treat IdP bypass routes as unmanaged identity domains Document each exception, assign a business owner, and set a deadline to remove the bypass or migrate it to standard federation. If the route remains, monitor it as a separate control surface.
• Use telemetry-led discovery before recertification cycles Run identity discovery across the full application estate before access reviews so that certifiers can see hidden accounts, alternate paths, and embedded credentials. Otherwise, recertification will validate an incomplete model.

Key takeaways

• Application identity risk often hides inside authentication paths, not just user accounts or directory roles.
• Cleartext credentials, IdP bypass routes, and inconsistent access enforcement create a control gap that central IAM cannot see on its own.
• Practitioners should combine discovery, secrets hygiene, and application-layer validation before trusting access reviews or recertification results.

Key terms

• 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.
• Hardcoded Credential: A secret such as a password, API key, or token embedded directly in source code rather than retrieved from a secure vault at runtime. Hardcoded credentials are one of the most common and dangerous NHI vulnerabilities.
• Application identity flow: An application identity flow is the complete path by which an application authenticates, authorises, and exchanges identity data with users or other systems. It includes direct login, federation, service-to-service authentication, and exception handling, which means hidden flows can quietly undermine enterprise identity governance.

What's in the full article

Orchid Security's full analysis covers the operational detail this post intentionally leaves for the source:

• Application-level findings on which identity controls are most frequently missing across discovered environments.
• The checklist mapping between common application gaps and the top missing identity controls.
• Operational guidance for using continuous discovery to surface hidden authentication paths and embedded credentials.
• Context on how the reported breach examples relate to credential exposure and bypassed identity controls.

👉 Orchid Security's full post covers the checklist findings, breach examples, and discovery detail.

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.