In my nearly two decades leading identity and risk programs, I’ve learned a sobering truth that every CISO eventually confronts: hackers don’t hack in — they log in. We often obsess over the perimeter and the sophistication of technical exploits, but many of the most damaging security failures I’ve witnessed didn’t involve a zero-day or an advanced technique. They involved a perfectly “legitimate,” authenticated access request approved by someone with little understanding of the risk they were authorizing.
I’ve seen this play out across the spectrum — from high-value production databases to seemingly low-risk ancillary systems that barely registered on the security team’s radar. In every case, the outcome looked the same: a valid user, a valid session and a valid approval that quietly opened the door to compromise.
This exposes two uncomfortable truths in modern identity security. Authentication — proving who someone is — has largely been addressed through MFA and SSO. Authorization — deciding what someone should be allowed to do — remains far more fragile. The deeper issue is not simply how access is granted, but what organizations believe they are actually governing.
What is your true denominator?
In many enterprises, identity programs operate inside a carefully defined bubble of “managed applications.” Teams invest heavily in onboarding workflows for the applications their IGA tools can see — often a few hundred systems at most. But meaningful risk assessment starts with a far more uncomfortable question: how does the organization know who has access to what across the entire environment?
This creates a true denominator problem. If an organization cannot account for the full scope of its applications, cloud tenants, service accounts and environments, any metric about MFA coverage or access reviews becomes largely performative. Being “100% covered” across a known subset offers little assurance if that subset represents only a fraction of the actual estate.
According to the 2025 MuleSoft Connectivity Benchmark Report, the average enterprise manages close to 1,000 applications, yet fewer than one-third are integrated into central integration platforms and systems of record — the same systems security teams often rely on to establish visibility and governance scope. Applications that never enter those systems are far less likely to be consistently inventoried, reviewed or governed from an access perspective.
Attackers understand this instinctively. They don’t limit their search to well-governed production systems. They probe the edges — legacy portals, test environments, shadow IT tools — precisely because those assets often sit outside formal governance. The Microsoft “Midnight Blizzard” breach highlighted this dynamic. The initial foothold wasn’t a mission-critical production system, but a legacy non-production test tenant that lacked the protections applied to the managed estate.
The SSO fallacy: Why authentication is not a guarantee
I’m often asked by business and technology leaders, “If we have SSO enabled, why do we still need to worry about granular access controls?” The underlying assumption is that once a user is authenticated through a central, secure portal, the hard work is done.
In practice, SSO functions more like a perimeter than a vault. Treating it as a comprehensive security control introduces two strategic blind spots — and exposes a critical downstream consequence when either one is exploited.
The coverage chasm
Few enterprises operate with complete SSO coverage. Not every asset is modern, eligible or capable of federated authentication. Legacy on-premises systems, specialized platforms, non-standard applications and shadow SaaS tools frequently sit outside the SSO umbrella.
When access decisions rely primarily on the presence of SSO, these unmodernized assets often receive less scrutiny. The result is a widening gap between the environments security teams believe they govern and the ones attackers actively target.
The bypass reality
Even where SSO is present, it is not invulnerable. Attackers increasingly focus on paths that circumvent central authentication entirely — local accounts, service credentials or session-hijacking techniques. The Snowflake breach offered a clear example of how adversaries can bypass federated controls and operate using otherwise valid access paths.
In these scenarios, authentication succeeds — or is avoided altogether — and the security outcome hinges on what that authenticated identity is allowed to do next.
Blast radius: The consequence of implicit trust
When a valid account is compromised — a “login” rather than a “hack” — the only meaningful constraint on damage is the blast radius of that identity. Broad, accumulated permissions turn a single compromised account into an enterprise-wide exposure. Narrow, well-understood access boundaries limit how far an attacker can move once inside.
In this context, access governance is less about denying access and more about constraining impact. It determines whether a successful login becomes a contained incident or a systemic failure.
The expanding non-human attack surface
The denominator continues to expand, not only through SaaS growth but through the proliferation of non-human identities and third-party access. Service accounts, API keys, secrets and automation identities now outnumber human users by an order of magnitude in many organizations, yet they are rarely governed with the same rigor.
At the same time, the modern enterprise increasingly relies on contractors, vendors and partners who require persistent access to internal systems. The Okta support system breach demonstrated how unmanaged third-party access can become an entry point. The compromise originated in a service account within a third-party support environment — an asset that existed outside the organization’s primary governance focus. Once compromised, that account enabled session hijacking and downstream exposure.
These incidents underscore a recurring pattern: access that falls outside the recognized denominator often receives less scrutiny, fewer controls and weaker accountability.
The rise of the ‘digital employee’
The denominator is expanding again as organizations deploy AI-driven automation and agentic systems that act as virtual workers. These are no longer simple scripts. They perform multi-step tasks across financial systems, data platforms and operational tooling.
When an AI agent is tasked with generating financial reports or orchestrating workflows across systems, it inherits broad access. If that agent makes an inappropriate access decision, accountability becomes ambiguous. The original manager approval often applies only at creation, not as scope and behavior evolve.
At the same time, shadow AI usage compounds the problem. Employees frequently use personal credentials to connect unmanaged AI tools to sensitive data sources, creating parallel access paths that never appear in formal identity systems. Identity governance, historically centered on human employees, is now confronted with a growing population of digital actors operating beyond traditional visibility.
Why managers default to the rubber stamp
If the most fragile point in an identity program had a physical location, it would be a manager’s inbox late on a Friday afternoon.
Rubber-stamping approvals is rarely a sign of negligence. It is usually the result of systemic context failure. Identity workflows routinely present approvers with access requests described in dense technical shorthand — group names and entitlement codes that require specialized knowledge to interpret.
A string like FIN-PRD-DB-USR-RW may be perfectly clear to an IAM engineer. To a business manager, it is indecipherable. Faced with multiple such requests, managers are left with an implicit choice: pause their work to investigate unfamiliar technical details or assume the request is legitimate and move on. In high-velocity environments, trust becomes the default and approval becomes reflexive.
When access requests are presented without clear, human-readable context, approval becomes an act of trust rather than judgment. The decision is recorded, but the risk is never truly evaluated.
Latent entitlements and the erosion of least privilege
One of the core goals of access governance is enforcing the principle of least privilege. In practice, modern workflows often undermine that goal through the accumulation of latent entitlements.
A familiar pattern repeats across organizations. An employee requests access for a specific project, receives it and retains it indefinitely. During subsequent access reviews, managers encounter entitlements that appear long-standing and therefore implicitly justified. Without visibility into actual usage, there is little incentive to revoke access that “hasn’t caused problems.”
This dynamic turns periodic reviews into exercises in administrative continuity rather than risk evaluation. Access is preserved because it exists, not because it is still necessary. Over time, entitlements accumulate and least privilege becomes aspirational rather than operational.
Why the problem keeps compounding
These challenges are intensifying as environments grow more distributed and change accelerates. New systems appear faster than governance models adapt. Non-human identities proliferate. Third-party relationships expand. Each additional layer increases the gap between access granted and access understood.
Adding more tools or more process checkpoints does not inherently improve decision quality. In many cases, it amplifies fragmentation and slows response without increasing confidence.
Reclaiming the decision
Access failures today rarely stem from missing controls. They stem from decisions made without sufficient context, ownership or accountability. As identity environments expand beyond employees to include contractors, automation and machine-driven processes, the gap between access granted and access understood continues to widen.
For CISOs, the challenge is no longer simply enforcing policy. It is determining whether access decisions meaningfully reduce risk — or merely document it. Until organizations can clearly answer who owns access decisions, what context informs them and how long those decisions remain valid, identity governance will continue to produce approvals without assurance.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?