Why Most IAM Deployments Fail Before They Ship
I spent three years managing IAM implementations across mid-market and enterprise clients. The ones that fail aren't failing because the technology is bad. The technology is fine. The failure happens because nobody at the company is willing to make the boring, unglamorous decisions about identity governance before they try to install the software. Let me explain what actually matters. An Identity And Access Management Solution isn't one product. It's a collection of capabilities that handle who people are, what they're allowed to do, and how that gets enforced across every system you own. You've got authentication, authorization, identity provisioning, access review, privileged access management, and often some kind of identity governance layer on top. All of it has to work together, or you get exactly the kind of friction that makes security teams hate each other.
The industry-standard approach these days involves a combination of SAML or OIDC for single sign-on, SCIM for automated provisioning and deprovisioning, and role-based access controls mapped to actual job functions rather than whatever spreadsheet someone maintained in 2019. That's the baseline. Anything less and you're managing access manually, which is how credential sprawl happens. I ran into a specific problem last year that I still think about. We were deploying an IAM platform for a healthcare organization with roughly 4,200 users spread across eight legacy clinical systems, seven commercial platforms, and about twelve AWS accounts. The requirement was straightforward on paper: federate authentication through Okta, automate provisioning via SCIM where possible, keep the rest on manual workflows. What they didn't tell me upfront was that three of those clinical systems used certificate-based authentication stored on hardware tokens, and one of them was built on a deprecated framework that didn't support SAML 2.0 at all. So here's what happened. We built the entire federated identity layer, validated it across forty-seven test scenarios, and then discovered that the legacy system with the hardware tokens had no LDAP backend. It wrote directly to its own proprietary database. SCIM was useless against it. SAML was useless against it. The workaround was a custom middleware script that polled the system's API every fifteen minutes, matched hardware token serial numbers to employee IDs from the HR source of truth, and pushed the authorization records into the target table. Took six weeks to build, three weeks to stabilize, and I still don't love how robust it is. But it works. And the alternative was keeping that system entirely isolated from the IAM program, which meant privileged users had to maintain separate credentials for it, which defeats the entire purpose.
That experience taught me something most vendors don't advertise. The systems that resist federation aren't always the obvious legacy ones. Sometimes it's a newer application that was built with a hard dependency on a specific identity provider that doesn't expose standard protocols. You will find those later than you want to. The only defense is a thorough discovery phase where you actually test protocol support on every system before you commit to an architecture.
Get the Full Details
Choosing an Identity And Access Management Solution Without Getting Sold the Wrong Thing
Most procurement conversations go like this: you talk to three vendors, they all say the same thing, you pick the one that's cheapest or the one your boss recognizes from a conference. That's how you end up with a platform that solves eighty percent of your problems and creates twenty percent new ones. Here's the thing people miss. The platform itself matters less than the data model it uses for identity resolution. Every IAM system has to answer one question: what is a user? Is it a person? An employee? A contractor? A service account? A machine? The answer determines everything downstream. Some platforms treat all of these as the same identity object with different attributes. Others create separate entities with different lifecycle rules. If your organization has a mix of active directory users, cloud identities, and service principals, and your platform doesn't distinguish between them at the data model level, you will eventually try to apply a password policy to a service account and break something. Role-based access control sounds simple. It isn't. The counter-intuitive part is that more roles usually means worse security, not better. When I've seen RBAC models with more than three hundred roles, it's always because someone tried to map roles to every possible permission combination rather than every job function. The result is role explosion. People get assigned three different roles that overlap, you can't tell who actually has access to anything, and access reviews become impossible because nobody knows which role is the source of truth for a given permission. The fix is to design roles around actual job functions, keep the total number under fifty for most organizations, and use attribute-based access control only for the edge cases that RBAC can't handle cleanly.
Privileged access management is where most platforms overpromise. They'll tell you they can manage all elevated credentials. What they actually mean is they can store them in a vault and play them back through an RDP session. That's not full PAM. Real privileged access management requires session recording, just-in-time elevation, and automated credential rotation. If a platform doesn't do all three, you're getting half a solution. For the record, I've seen companies use "we have a privileged session recording feature" as their compliance evidence during audits. It's not enough. Auditors will ask about credential rotation and just-in-time, and if you can't answer yes to both, you're non-compliant regardless of session recording. There's a bottleneck that nobody warns you about. The connection to your HR system. Every provisioning workflow ultimately traces back to a hire event in your human resources platform. If that integration is weak or one-way, your IAM platform is flying blind. I recommend you verify two things before signing any contract: first, that the HR integration supports both creation and termination events in real time, not batched at midnight. Second, that the termination event actually triggers deprovisioning across all connected systems, not just a flag in the IAM database. I've seen three separate deployments where deprovisioning only worked for the primary system. The secondary systems kept running with active accounts for weeks or months after the employee left. That's a compliance violation waiting to happen. Cost is another factor that doesn't work the way vendors describe it. Most platforms price per identity, which sounds fair until you realize that service accounts, machines, and external contractors all count as identities. A hospital with ten thousand employees but fifty thousand IoT medical devices and ten thousand service accounts will get a very different bill than the retail company with one hundred thousand employees but almost no infrastructure identities. Make sure you understand what counts as an identity in your specific environment before you get a quote. The numbers shift dramatically.
Open source options exist. FreeIPA, Keycloak, Linux-PAM. They're viable for small environments or organizations with strong internal engineering capacity. The tradeoff is that you own the maintenance, the upgrades, the integrations, and the compliance reporting. A managed platform shifts most of that burden but locks you into their ecosystem. Neither choice is wrong. They're just different commitments. The implementations that work are the ones where the security team and the infrastructure team agree on the scope before any software gets installed. If they haven't discussed which systems are in scope, which are excluded, and why, you're going to find out about the exclusions after you've already built the platform. Fixing that retroactively is expensive. Talking about it upfront costs nothing.
