Nobody talks about the moment it clicks. You’re sitting in an incident review, walking backward through an attacker’s lateral movement, and you realize the whole breach didn’t start with a firewall gap or an unpatched CVE — it started because a contractor who left eight months ago still had an active account. Full access. Never deprovisioned. Their credentials got phished, and that was it. That is the quiet, unglamorous, entirely preventable way most breaches actually happen. Not through Hollywood-style zero-days, but through identity sprawl, orphaned accounts, and the organizational failure to treat Identity and Access Management as the foundational security discipline it has become. If you’ve spent any real time in enterprise security, you’ve lived some version of that story. The frustrating part isn’t that the technology doesn’t exist to prevent it — it absolutely does. The frustrating part is how consistently organizations underinvest in the operational rigor required to make it work.
IAM Is Not a Product — It’s an Organizational Discipline
There’s a persistent and dangerous misconception in the industry that IAM is something you buy and deploy. You bring in a vendor, stand up a platform, call it identity governance, and check the box. That framing misses the point almost entirely. IAM is a set of continuously enforced processes that governs who has access to what, under what conditions, and for how long — and it requires sustained operational commitment from IT, security, HR, and business leadership working in genuine coordination. When that coordination breaks down, the technology doesn’t save you.
The scope is also broader than most security teams initially appreciate. IAM covers employees, contractors, partners, service accounts, machine identities, and increasingly non-human identities like CI/CD pipeline tokens and API keys. Each category carries its own lifecycle, its own risk profile, and its own provisioning logic. Treating all of them with the same level of discipline is where organizations consistently fall short. Machine identities in particular have become an enormous blind spot — companies that have excellent visibility into their human workforce often have almost no coherent inventory of the service accounts and API credentials running across their infrastructure. Those are identities too, and they need governance just as much as the human ones.
Okta and Entra ID — Why Both, and Why That Question Matters
One of the most common architectural conversations in enterprise IAM right now is the Okta-versus-Microsoft-Entra-ID debate, and framing it as a competition fundamentally misunderstands how large organizations actually operate. In practice, most enterprises of meaningful scale are running both — and that’s not a failure of standardization, it’s a reflection of real-world complexity.
Microsoft Entra ID (formerly Azure AD) is deeply embedded in the Microsoft ecosystem. If your organization runs Microsoft 365, Teams, SharePoint, and Azure workloads, Entra ID is effectively your identity backbone for that surface area. The integration depth is unmatched, the conditional access policies are mature, and the licensing economics make it difficult to route around. What Entra ID is less elegant at is heterogeneous environments — the organizations also running AWS, Salesforce, Workday, dozens of SaaS applications, and a mix of on-premises legacy systems. That is where Okta’s value becomes clear. Okta was purpose-built as an identity broker for multi-vendor environments. Its application catalog is extensive, its universal directory handles complex attribute mapping cleanly, and its lifecycle management capabilities were designed from the ground up for organizations that don’t live entirely in the Microsoft stack.
The honest answer to “why both?” is that most large enterprises didn’t architect their identity environment from scratch — they accumulated it over years of acquisitions, organic growth, and shadow IT. Okta often ends up as the customer-facing or workforce identity layer that federates into Entra ID, with Entra ID handling the Microsoft-native workloads and serving as the source of truth for that domain. That architecture works. What doesn’t work is assuming one platform covers everything and leaving the gaps ungoverned. The choice of tooling is far less important than the clarity of your identity architecture — knowing which directory is authoritative for which population, how attributes flow between systems, and where your provisioning and deprovisioning actually execute.
RBAC, ABAC, and the Access Model Most Organizations Haven’t Finished Building
Role-Based Access Control is the starting point most organizations reach for, and for good reason — it’s conceptually clean and operationally manageable at moderate scale. You define roles, you map permissions to those roles, you assign users to roles. In theory, managing access becomes a matter of managing roles. In practice, role explosion is the failure mode that quietly undermines every large RBAC implementation. Organizations accumulate roles the way they accumulate debt — gradually, then suddenly. I’ve seen environments with thousands of roles where less than fifteen percent were actively assigned to more than one user. At that point you don’t have RBAC, you have the appearance of RBAC with the operational complexity of individual permission management underneath it.
Attribute-Based Access Control addresses some of those structural limitations by making access decisions dynamically, based on contextual attributes rather than static role assignments. Instead of defining a role that grants access to financial records, an ABAC policy might express: grant access if the user’s department is Finance, the resource classification is Confidential, the user’s location is on-network, and the time is within business hours. That policy applies universally without requiring a separate role for every combination of those conditions. The tradeoff is policy complexity — ABAC systems require more thoughtful design upfront, and debugging access failures in a complex attribute-driven policy engine is genuinely harder than tracing a role assignment. Neither model is universally superior. Most mature organizations are running a hybrid, using RBAC as the structural foundation for coarse-grained access and layering ABAC policies on top for fine-grained, context-sensitive enforcement — particularly for sensitive resources where access should adapt to risk signals in real time.
The principle of least privilege lives at the intersection of both models, and it’s more of a commitment than a configuration. Giving users the minimum access required to perform their function sounds obvious, but it requires continuous effort to maintain. Access tends to accumulate over time through role creep — the developer who gets temporary elevated access during an incident and never has it revoked, the manager who inherited their predecessor’s permissions during an org change, the service account that was granted broad access during a project and then forgotten. Least privilege isn’t a setting you enable. It’s a discipline you enforce through access reviews, attestation cycles, and automated detection of access that’s no longer being exercised.
Identity Lifecycle Management — The Part That Actually Keeps Organizations Secure
If forced to identify the single most impactful area of IAM investment, identity lifecycle management wins without much competition. Everything else — strong authentication, fine-grained authorization, conditional access policies — depends on accurate, current knowledge of who should have access in the first place. If your identity data is stale, your entire security posture is built on an unstable foundation.
The lifecycle spans from the moment someone joins an organization to the moment they leave, and every transition in between. Joiners need accounts provisioned quickly enough to be productive on day one, with access appropriate to their role and nothing beyond it. Movers — people who change roles, departments, or employment type — represent an often-underappreciated risk. When someone moves from an individual contributor to a management role, or from one business unit to another, their old access rarely gets fully revoked at the same time their new access is provisioned. Over time, movers accumulate a patchwork of permissions from every role they’ve ever held. That’s not just a theoretical risk — it’s a real and measurable attack surface. Leavers are the most obvious failure mode, and yet deprovisioning failures remain stubbornly common. The problem isn’t usually the primary HR-to-identity-provider automation, which most mature organizations have in place. It’s the long tail of downstream systems that never received the termination signal — the legacy application that isn’t integrated with your IDP, the shared credentials that were handed to a contractor and never rotated, the Slack channel where a former employee is still an admin.
Good lifecycle management requires HR as a genuine partner, not just a data source. When HR systems are authoritative and changes flow automatically into identity platforms, the joiner-mover-leaver process can be largely automated and consistent. When HR data is unreliable, manual, or poorly integrated, the identity environment becomes a reflection of that chaos. I’ve seen organizations where contractors never had formal offboarding workflows because they were never formally tracked in the HR system — they existed only in the minds of the hiring managers and the access they’d accumulated over time. That is a governance failure with real security consequences. The technical solution exists. The organizational problem is harder.
Where the Industry Is Heading — and What Still Needs to Change
The trajectory of enterprise IAM is moving toward continuous verification rather than point-in-time authentication. Zero Trust as a framework, whatever its marketing baggage, correctly identifies the core insight: the network boundary is no longer a meaningful security perimeter, and access decisions should be made and re-evaluated continuously based on real-time risk signals — device health, user behavior, geolocation, time of access, resource sensitivity. The identity platform is the enforcement point for all of that. This shift is driving deeper integration between IAM tooling and security operations — SIEMs ingesting identity events, UEBA platforms building behavioral baselines from authentication data, SOAR playbooks automatically suspending accounts when anomalous activity is detected.
What hasn’t changed as fast as it should is the organizational maturity to operate these systems with the discipline they require. Identity governance reviews still get skipped when engineering teams are busy. Access certifications get rubber-stamped by managers who don’t have the context or the time to make meaningful decisions. Service account inventories remain incomplete. The technology is ahead of the process in most organizations, and that gap is where risk accumulates. The companies that get IAM right aren’t necessarily running more sophisticated tooling — they’re the ones where identity hygiene is a first-class operational priority, where access reviews have executive accountability, and where the security team has enough credibility with business leadership to push back when access requests don’t meet the standard.
Summary and Conclusion
Identity and Access Management is not a solved problem, and it won’t be until organizations treat it with the same seriousness they extend to endpoint protection or perimeter security. The breach scenarios that keep CISO teams awake at night — compromised credentials, insider threats, supply chain access abuse — all run through identity. Platforms like Okta and Microsoft Entra ID provide the technical infrastructure to address those risks, but they are tools in service of a broader organizational discipline, not substitutes for it. RBAC and ABAC give security teams a vocabulary for expressing access policy at scale, but least privilege requires continuous operational enforcement to mean anything. And above all, identity lifecycle management — the rigorous governance of who has access, as they join, move through, and leave an organization — is the unglamorous, foundational work that separates organizations with a real security posture from those with the appearance of one.
The attacks will continue to run through identity because that’s where the leverage is. The defenders who close that gap won’t do it with the next product launch. They’ll do it by building organizations where identity governance is taken seriously at every level — from the engineer who raises a ticket to rotate a service account credential, to the executive who holds their business unit accountable in the quarterly access review. That organizational commitment is harder to buy than software, and harder to audit than a configuration. It’s also the only thing that actually works.
Amir Ebrahimi 
Leave a comment