Why do identity platforms often look stronger than they are in practice?

Why This Matters for Security Teams

Identity platforms often create confidence at the login layer while the harder control problem sits behind it: entitlement drift, stale approvals, and inconsistent revocation. That gap matters because attackers do not need to break authentication if they can inherit overly broad access that was never revalidated. The right question is not whether the platform can issue a token, but whether access remains appropriate after the token is issued.

NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a useful signal of how often “managed identity” still means poorly governed entitlement. NIST’s Cybersecurity Framework 2.0 reinforces that governance must extend beyond authentication into access lifecycle management, review, and continuous control validation. In practice, many security teams discover the weakness only after a dormant service account, API key, or delegated app is reused in an incident, rather than through a scheduled access review.

How It Works in Practice

Identity platforms are strongest when they centralise sign-on, federation, and policy enforcement at the perimeter of access. They look weaker when organisations assume that central login automatically means central control. In reality, entitlement data often lives across application owners, cloud consoles, SaaS role stores, PAM systems, and ticketing workflows. That fragmentation means the platform may authenticate a principal correctly while still allowing broad, outdated, or duplicate access.

Practitioners reduce this gap by treating identity as a lifecycle problem, not a login event. That means:

• mapping every account, service principal, and API key to an owner and business purpose;
• reviewing entitlements against current job function or workload purpose, not original approval history;
• rotating and revoking secrets on a defined schedule, especially where long-lived credentials remain in CI/CD, code, or scripts;
• using policy-as-code and automated reconciliation so access changes are validated continuously rather than only during quarterly review;
• measuring revocation latency, orphaned access, and privilege creep as first-class security metrics.

This is where the NHIMG research base is instructive. The Top 10 NHI Issues and the 52 NHI Breaches Analysis both show a common pattern: compromise is often enabled by access that outlived its intended context. Standards guidance is clear that identity assurance is only one part of the control stack; operational governance has to catch what authentication cannot. These controls tend to break down in fast-moving cloud environments with many app owners because access changes outpace review workflows.

Common Variations and Edge Cases

Tighter identity governance often increases operational overhead, requiring organisations to balance stronger control against developer friction, support load, and release velocity. That tradeoff is real, especially where teams rely on temporary vendor access, shared platforms, or machine identities that cannot be interrupted during peak service windows.

Best practice is evolving on how far automation should go. Some environments can enforce near-real-time entitlement reconciliation, while others still depend on periodic certification for legacy systems. There is no universal standard for this yet, but the direction is consistent: reduce the time between entitlement creation, business change, and entitlement removal. For high-risk paths, current guidance suggests prioritising short-lived credentials, explicit ownership, and automated offboarding over broad manual approvals.

The edge cases are usually the ones that look “managed” on paper but are operationally opaque: federated SaaS apps with separate admin roles, service accounts embedded in pipelines, and integrations where no one team owns the full access path. Those cases need extra scrutiny because the identity platform may only see the first hop, not the downstream permissions that actually matter.

Related resources from NHI Mgmt Group

• Why do lending platforms need stronger identity controls when they remove application steps?
• How should security teams compare Microsoft 365 admin tools with broader identity governance platforms?
• Who should own identity-related compliance controls in practice?
• How should teams govern identity estates they cannot fully see?