Why do identity-aware proxies still leave NHI risk in place?

Because many infrastructure resources still depend on service credentials, tokens, or keys outside the proxy session. If those credentials remain valid after access ends, the organisation still has NHI exposure, even if user login is centralised. The risk shifts from authentication to entitlement persistence and secret sprawl.

Why Identity-Aware Proxies Do Not Eliminate NHI Exposure

Identity-aware proxies centralise login and session enforcement, but they do not automatically control the secrets that workloads use after the proxy decision is made. Service accounts, API keys, certificates, and bearer tokens often remain valid outside the proxy path, which means the attack surface simply moves from front-door authentication to entitlement persistence. That is why NHI governance still matters even when the user experience looks unified. The pattern is visible in NHIMG research such as the Ultimate Guide to NHIs, which reports that 97% of NHIs carry excessive privileges.

For security teams, the practical mistake is assuming that a proxy session equals full access control. In reality, the proxy may protect one request path while downstream workloads continue to trust long-lived credentials elsewhere. That gap is exactly where secret sprawl, stale permissions, and lateral movement persist. Current guidance from the NIST Cybersecurity Framework 2.0 still points to identity, access, and asset governance as separate control problems, not a single solved layer. In practice, many security teams encounter credential abuse only after a downstream service has already been reached through a token the proxy never touched.

How the Proxy Model Leaves the Real Risk Untouched

An identity-aware proxy typically evaluates who is making a request, then brokers access to the protected application or resource. That is useful for human sessions and for some web-facing workloads, but it does not replace workload identity management. If a database password, cloud API key, or certificate is embedded in an application, the proxy cannot revoke it when the session ends unless another system rotates or invalidates it.

• Proxy policy controls the entry point, but not every downstream secret.
• Long-lived credentials outlast the session and can be reused from elsewhere.
• Service identities often have broader privileges than the proxy policy suggests.
• Audit trails may show the proxy approval while missing tool-to-tool activity after access is granted.

That is why NHI programs focus on lifecycle controls, rotation, vaulting, and offboarding. NHIMG research in the Ultimate Guide to NHIs — Key Challenges and Risks notes that 71% of NHIs are not rotated within recommended time frames, and 91.6% of secrets remain valid five days after notification. Those numbers show why the proxy boundary is only one layer in the chain. A stronger design pairs the proxy with just-in-time credential issuance, short TTLs, and revocation hooks tied to the actual secret source, not only the access gateway. Best practice is evolving toward request-time enforcement and workload-aware controls rather than static entitlements alone. These controls tend to break down in legacy environments where applications share credentials, rotation is manual, and the proxy cannot see every backend call.

Where the Proxy Helps, and Where It Still Breaks Down

Tighter proxy enforcement often improves visibility, but it also adds operational overhead, requiring organisations to balance control coverage against application compatibility. That tradeoff is especially sharp in mixed environments where modern apps sit beside legacy systems. The proxy can be effective for central authentication, policy logging, and coarse-grained access gating, but it cannot solve secret sprawl by itself. For that reason, current guidance suggests treating proxies as one component of a broader zero standing privilege model rather than as the identity control plane for all NHIs.

There is no universal standard for this yet, but mature programs usually combine the proxy with secrets managers, workload identity, and continuous entitlement review. The Top 10 NHI Issues resource is useful here because it frames the common failure modes: excessive privilege, poor visibility, and missing rotation. In practice, a proxy still leaves NHI risk in place when credentials exist outside its lifecycle, when backend services trust static tokens, or when revoked sessions do not trigger downstream invalidation. That is why practitioners should measure success by whether secrets expire, rotate, and disappear on schedule, not just by whether login passes through a proxy.

Related resources from NHI Mgmt Group

• Why do secrets create disproportionate risk in NHI environments?
• How should teams reduce the risk from exposed NHI secrets?
• When does short-lived identity still leave too much risk?
• When does short-lived token use still leave material NHI risk?