Last updated: August 2026
Cloud identity management is the practice of running authentication, authorization, user lifecycle, and audit as a hosted service instead of as software you install and babysit yourself. Cloud IAM solutions come in three delivery models: multi-tenant IDaaS, self-hosted open source, and managed dedicated deployments. They differ far less in features than in three things that decide the outcome: who holds your user data, how pricing scales as you grow, and how hard it is to leave.
Most “which cloud IAM solution should we buy” conversations start with a feature matrix. That is the wrong place to start, because by 2026 every serious option does SSO, MFA, and social login. The comparison table is a tie. What actually separates these products shows up eighteen months later, in your invoice and in how trapped you feel.
This guide covers what cloud identity management actually includes, the three delivery models and their real tradeoffs, the criteria worth arguing about, and where the shared responsibility line sits when a vendor says “managed.”
What is cloud identity management?
Cloud identity management is a hosted system that answers four questions for every application you run:
| Job | The question it answers | Typical standards |
|---|---|---|
| Authentication | Who is this? | OIDC, SAML 2.0, WebAuthn |
| Authorization | What are they allowed to do? | OAuth 2.0 scopes, RBAC, ABAC |
| User lifecycle | Who joined, changed role, or left? | SCIM 2.0, LDAP federation |
| Audit | Who did what, and when? | Event logs, SIEM export |
Take any of those four away and you do not have identity management, you have a login box. Plenty of products marketed as cloud IAM are strong on the first and thin on the other three. The lifecycle question in particular is where teams get hurt, because deprovisioning failures are quiet. Nobody files a ticket saying “my access still works six months after I left.”
The “cloud” part simply means somebody else runs the servers, patches the CVEs, and stays awake during your traffic spike. It does not tell you who holds the data or where.
Cloud IAM vs on-premises IAM
| On-premises IAM | Cloud IAM | |
|---|---|---|
| Upgrades and patching | Your team, on your weekends | The provider |
| Availability | You design and staff it | Contractual, via SLA |
| Data location | Wherever you put it | Wherever the provider puts it, unless you can pin it |
| Scaling | Buy capacity ahead of demand | Elastic, but often metered |
| Customization | Unlimited | Bounded by what the vendor exposes |
| Cost shape | Capital plus salaries | Operating expense, grows with usage |
The honest summary: on-premises trades money and headcount for control, and cloud trades control for time. The interesting options are the ones that refuse to make that trade cleanly, which is the third model below.
The three delivery models for cloud IAM solutions
Almost every cloud IAM solution on the market is one of these three shapes. Picking the shape matters more than picking the brand.
1. Multi-tenant IDaaS
Your realm is a logical slice of a large shared platform. Think of the well-known hosted identity providers, several of which are compared in our IDaaS landscape roundup.
Good at: fastest possible start, polished dashboards, deep first-party integrations, someone else’s problem at 3am.
Watch for: pricing usually tracks monthly active users, so your identity bill grows at the same rate as your success. Customization stops where the vendor’s extension points stop. And because the data model is proprietary, leaving means an export and a rewrite rather than a move.
2. Self-hosted open source
You run something like Keycloak, a CNCF incubating project, on your own infrastructure.
Good at: no per-user pricing, complete control over data location, unlimited customization through provider SPIs and custom themes, and no vendor who can change the commercial terms underneath you.
Watch for: you now operate a security-critical, stateful, always-on service. That means clustering, cache tuning, database failover, certificate rotation, upgrade testing across breaking releases, and a rota of humans who know how it works. Teams routinely underestimate this and discover the true cost during their first unplanned outage.
3. Managed dedicated open source
A provider runs an open source stack for you, on infrastructure dedicated to you rather than shared with other tenants. This is the model Skycloak uses.
Good at: the operational burden goes away, but the data model stays standard and the pricing is tied to infrastructure rather than to how many people use your product. Because the underlying software is open source, the exit path is a real migration rather than a rewrite.
Watch for: a smaller vendor ecosystem than the household IDaaS names, and you should confirm that “managed” means dedicated rather than a shared pool wearing a nice logo.
| Multi-tenant IDaaS | Self-hosted OSS | Managed dedicated OSS | |
|---|---|---|---|
| Time to first login | Hours | Days to weeks | Hours |
| Ops burden | None | High and permanent | None |
| Pricing driver | Monthly active users | Infrastructure plus salaries | Infrastructure |
| Data residency control | Vendor regions | Total | Selectable |
| Customization ceiling | Vendor extension points | No ceiling | Effectively no ceiling |
| Cost of leaving | High, proprietary model | None, you already run it | Low, standard stack |
What to actually argue about when choosing
Once you accept that the feature grids all tie, these are the questions that change the answer.
Does the pricing model match how you make money?
Per monthly active user pricing is fine for internal tools with a stable headcount. It is punishing for consumer products, marketplaces, and anything with a free tier, because you pay for users who generate no revenue. Run the arithmetic at three times your current scale before signing anything. Our IAM ROI comparison walks through how the models diverge, and the pricing calculator will do the boring part for you.
Where does the user data physically live?
For GDPR, and for most public sector and healthcare procurement, “in the EU” is a requirement rather than a preference. Ask which region, whether backups and logs stay in that region too, and whether support staff can access production data from elsewhere. That last one surprises people.
Are the protocols standard all the way down?
Standards are your exit strategy. If your applications speak OIDC and SAML, and your provisioning speaks SCIM, then the identity layer is replaceable. If any part of the integration relies on a proprietary SDK doing something non-standard, that part has to be rebuilt when you move. Our guide on SAML vs OIDC covers where each belongs.
How bad is the exit?
Ask the question before you sign, while you still have leverage: can you export users with their password hashes, or only with a forced reset for everyone? A migration that requires every user to reset their password is not a migration, it is a churn event. We wrote a whole identity provider exit plan on this, because it is the single most expensive thing teams skip.
What happens when you need behaviour the product does not have?
Every identity project eventually needs something odd. A legacy attribute mapped into a token, a bespoke step in the login flow, an integration with an internal system nobody outside your building has heard of. Find out now whether that is a support ticket, a feature request into a queue you do not control, or something you can just write.
What “managed” actually covers
“Managed” is doing a lot of unexamined work in most vendor copy. It is worth being precise, because the gaps are where incidents live.
| Layer | Typically the provider | Typically you |
|---|---|---|
| Infrastructure, OS, patching | Yes | No |
| Software upgrades | Yes | Approving the window |
| Backups and restore testing | Yes | Confirming the restore actually works |
| High availability and failover | Yes | No |
| Realm and client configuration | No | Yes |
| Authentication flow design | No | Yes |
| Who has admin rights | No | Yes |
| Application integration | No | Yes |
The pattern: providers own the platform, you own the configuration. Most identity incidents are configuration incidents, which means “managed” removes the outage risk you were worried about and leaves the one you were not. Budget for someone who understands your flows regardless of who runs the servers.
Moving an existing system to cloud IAM
Two things decide whether this goes well.
Password hashes are portable more often than people assume. Keycloak, for instance, can validate legacy hashes through a custom password hash provider, then transparently rehash them on first login, which means users keep their existing passwords through a migration and never see a reset email. If your current provider will not export hashes at all, that constraint shapes the entire plan and you should find out on day one.
Do not cut over in one night. Running both systems in parallel and moving traffic gradually turns a high-stakes launch into a series of small reversible steps. Our dual-run migration guide covers the routing and session details.
If you are federating an existing directory rather than migrating off a competitor, that is a different and generally easier job. See the Active Directory integration guide or the LDAP integration guide.
Cloud identity management FAQ
What is cloud identity management?
Cloud identity management is the delivery of authentication, authorization, user lifecycle, and audit as a hosted service rather than as software you install and operate. A cloud IAM solution centralizes login for all your applications, enforces access policy, provisions and deprovisions accounts, and produces an audit trail, with the provider handling infrastructure, patching, and availability.
What is the difference between cloud IAM and IDaaS?
IDaaS (identity as a service) usually refers specifically to the multi-tenant subscription model, where your tenant is a slice of a shared platform. Cloud IAM is the broader category, and it also covers self-hosted deployments in your own cloud account and dedicated managed deployments. Every IDaaS product is cloud IAM, but not every cloud IAM solution is IDaaS.
Is cloud IAM secure enough for regulated industries?
Yes, with conditions attached. Regulated buyers generally need data residency in a named region, an audit trail exportable to their own SIEM, enforceable MFA, role separation for administrators, and a contractual SLA. Those are procurement questions rather than technical ones, and the answer depends on the provider rather than on the fact that it is hosted.
How much do cloud IAM solutions cost?
It depends entirely on the pricing driver, not the sticker price. Per monthly active user models scale with your user count, so cost tracks growth. Infrastructure-based models scale with load, so cost tracks traffic. Two products with similar list prices can differ by an order of magnitude at scale, which is why you should model your own numbers at three times current volume rather than compare monthly figures.
Can we move to cloud IAM without forcing a password reset?
Often yes. Some platforms can validate legacy password hashes on first login and transparently rehash them, so users never notice. This depends on your current provider being willing to export hashes, which is worth confirming before you commit to anything.
Do we still need our own identity expertise if the platform is managed?
Yes. A managed provider owns uptime, patching, and infrastructure. You still own realm configuration, authentication flows, role design, and which applications trust which clients. Most identity incidents come from configuration rather than infrastructure, so keep someone who understands your setup.
Where Skycloak fits
Skycloak is the third model: managed, dedicated, and built on Keycloak, which means standard protocols the whole way down and no per-user pricing to punish you for growing. You get an isolated deployment in a region you choose, upgrades and high availability handled, and full admin console access for the configuration that is genuinely yours to own.
Because the stack underneath is open source, your exit is a migration rather than a rewrite. We think that is the right way round: staying should be a decision you keep making, not one made for you by the cost of leaving.
Have a look at Skycloak hosting for the deployment model, or pricing to see how infrastructure-based cost compares against the per-user quote you are probably holding.
