Cloud Identity and Access Management (Cloud IAM)
Cloud Identity and Access Management (Cloud IAM), usually called Identity as a Service (IDaaS), is an identity provider that someone else operates: authentication, single sign-on, the user directory, provisioning and access policy, delivered as a managed service that the organization configures as a tenant instead of installing and running. It becomes the platform the workforce, and often partners and customers, sign in through for cloud, software-as-a-service (SaaS) and on-premises applications alike. The name is easily confused with the permission system each cloud provider has for its own accounts, roles and resources, which is a different subject and the one CIEM covers. Moving to IDaaS removes the work of running identity infrastructure and replaces it with a dependence on the provider's availability, release cycle and handling of data, and the decisions that remain with the buyer follow from that dependence.
What Moves to the Provider, and What Stays
An IDaaS platform bundles what used to be separate products: single sign-on (SSO) over OpenID Connect and SAML, multi-factor and passwordless authentication, conditional access, a directory, and provisioning into applications with SCIM (System for Cross-domain Identity Management). The provider runs the service, patches it, scales it and holds its signing keys. The organization keeps everything that decides whether the service is secure in its own hands: the tenant configuration, the administrator accounts, the federation trusts and application registrations, the identity data fed in from HR and governance systems, and the plan for the day the service is unavailable. Moving to IDaaS therefore takes servers out of the budget but not the identity team out of the organization: most incidents involving IDaaS happen on the organization's side of that line, and a programme that assumes the provider covers security leaves exactly those items without an owner once the implementation project ends.
Providers offer the service in three forms. A multi-tenant SaaS platform is the common case, cheapest to run and updated by the provider on its own schedule. A dedicated instance runs the same software for one customer, with more say over regions and upgrade timing. Some providers also ship their platform as managed software that runs in the customer's own cloud subscription, which gives the most control over where data sits and returns part of the operating burden. The form decides who controls when the software changes and where the data sits, so it constrains the residency and exit questions below before either is asked. Each platform also offers extension points (scripts, hooks and custom flows) for requirements the configuration cannot express. They are what makes a platform fit an unusual estate, and they are written in the provider's own model, so every one of them is code that has to be maintained through the provider's releases and rewritten if the organization ever leaves.
The Tenant Is the Target
An IDaaS tenant decides who can sign in to everything, and attackers treat it accordingly. The most damaging attacks on it exploit no flaw in the provider. They are configuration changes made from a valid administrator session: a new federation trust to an identity provider the attacker controls, which lets them sign in as any user; an application registration granted broad access to mail or files; an extra authentication method added to an administrator's account; an account quietly excluded from a conditional access policy. Every preventive control accepts these changes, because an administrator made them. The way in is often the organization's own help desk, persuaded to reset an administrator's second factor over the phone.
Protecting the tenant starts with its administrators. Administrative roles should be held without standing privileges, in accounts separate from everyday ones, authenticated with phishing-resistant credentials, and with a recovery procedure that the help desk cannot shortcut. Detection comes next. Identity Threat Detection and Response (ITDR) reads the tenant's audit log for exactly the changes listed above and can revoke sessions when one appears. The audit log inside the service is kept only for a limited period, which often depends on the licence tier, so an organization that has to show an auditor who changed a policy a year ago needs to export it to its own SIEM or archive.
Even without an attacker, a tenant drifts. An exclusion added during an incident is never removed, a legacy protocol is switched back on for one application, a test application keeps production permissions. The provider's release cycle adds its own drift, because new features arrive with defaults the organization did not choose. Each of these is a gap nobody decided to leave open, and the console shows only the current state, not how it came about, so nobody notices until an attacker or an auditor does. Identity Security Posture Management (ISPM) compares the tenant against a baseline and reports where it has moved away from it. Organizations that manage the configuration through the provider's management interface as versioned code, as Policy as Code does for authorization policy, get the same comparison from a diff and can reject changes that bypassed review.
When the Provider Is Down
A provider outage is outside the organization's control and usually hits many customers at once. The service level agreement pays service credits for it and does nothing for continuity. What still works during an outage depends on how the applications were built. An application that validates tokens locally against the provider's cached signing keys keeps serving users who already have a session, until that session or its token expires. New sign-ins, token refreshes and step-up prompts all fail. Session and token lifetimes are therefore an outage budget as well as a security setting, and the two pull in opposite directions: short lifetimes limit a stolen session, long ones let users work through an outage.
The organization's own preparation is the same as for any central identity provider, and the SSO article covers it: break-glass accounts that do not depend on the provider, tested regularly, and a list of the systems that must stay reachable without it. For IDaaS, the plan also needs the provider's region and failover arrangement, and the answer to whether the administration console stays reachable when sign-in does not, because during an outage that console is the only place where sessions can be extended or a failing policy switched off, and an administrator who cannot sign in to it can only wait for the provider.
Where the Identity Data Lives
The directory holds personal data about every employee, and the sign-in logs add IP addresses, devices, locations and times. Under the EU General Data Protection Regulation (GDPR) the provider is a processor for that data and needs a processing agreement, and any transfer outside the European Economic Area needs a legal basis. Data residency options often cover the directory without covering everything else. Logs, telemetry, backups, the provider's support access and its subprocessors are worth asking about individually, because an answer for "customer data" may not include them, and a gap found by the data protection officer after the contract is signed is expensive to close. In Germany, sign-in logs make an IDaaS platform a technical system suitable for monitoring employees, and introducing it is therefore subject to co-determination by the works council (Betriebsrat), which can halt a rollout that started without an agreement.
The EU NIS2 Directive treats the provider as part of the organization's supply chain. It requires essential and important entities to manage supply-chain security and to enforce access control and multi-factor authentication, and an identity provider is the supplier on which both of those depend. Outsourcing the service does not outsource the accountability: when the provider fails or is breached, the supervisor asks the organization, which then has to show the contract terms, the provider's assurance reports and its own incident arrangements. For financial entities, the Digital Operational Resilience Act (DORA) goes further and requires an exit strategy for ICT services that support critical or important functions. An IDaaS platform almost always supports them.
Planning the Exit Before the Entry
An organization rarely chooses the moment it leaves an identity provider. A price rise at renewal, an acquisition that brings a second provider into the estate, a product the provider discontinues, a breach at the provider or a supervisor asking for the exit strategy can each force the move, and an organization that cannot leave has no answer to any of them, including at the negotiating table. Leaving is also harder than the use of open standards suggests. Users and groups move easily through SCIM or a bulk export. Applications move because OpenID Connect and SAML are standards, but each one has to be registered again with a new issuer, client credentials and certificates, and with hundreds of applications this is most of the migration. Some things do not move at all. Password hashes may not be exportable, or not in a form the new provider can verify, which leaves either a reset for every user or a migration at sign-in in which the new provider checks each password against the old one. One-time-password seeds and push-notification enrolments usually do not export, so users enrol their second factor again. Passkeys are bound to the domain of the sign-in page. If that page runs on the provider's domain, every passkey the workforce has registered belongs to that domain and is lost when the organization leaves.
Most of this is settled in the first weeks of the rollout, deliberately or by default, while changing it costs nothing; a year later every enrolled passkey and every registered application depends on the choice. Serving the sign-in pages, and where the provider allows it the token issuer, from a domain the organization owns keeps passkeys and application configuration tied to the organization rather than the provider, although the new provider still has to be able to take over the stored passkey public keys. Keeping the authoritative identity data in the HR and governance systems, with the IDaaS directory fed from them, means the directory can be rebuilt elsewhere. Extension logic kept to a minimum and documented is logic that can be rewritten. Where a migration or a second provider is foreseeable, an Identity Orchestration layer in front of the providers lets applications integrate once and stay unchanged when the provider behind it changes. The contract should state the export format for all tenant data at termination and a transition period during which both providers can run.
Beyond the Workforce
Contractors, partners and suppliers are often given accounts in the same tenant, because an identity the organization never hired still needs proofing, a sponsor, conditional access and an audit trail, and a shared account provides none of them. Where the partner runs its own identity provider, federating with it avoids a second set of credentials, but it moves the joiner and leaver process to the partner. No HR system records the end of a contractor's engagement, so external accounts outlive the work they were created for unless something ends them, and the sponsor's periodic confirmation and an expiry date on every external account become the controls that matter. Third-Party Identity covers accepting identities from external providers. Customer identity is usually a separate tenant or product, with different scale, consent and branding requirements.
AI agents are the newest population in the tenant. Several providers now register agents as OAuth clients or as a distinct identity type, and the difference matters less than three properties the buyer should check. Each agent needs an accountable owner and a lifecycle, which is what an AI agent registry holds. An agent acting for a user needs a token that names both, which OAuth Token Exchange provides. And agents need to appear in the same audit trail and access reviews as people, because an investigation that has to reconstruct what an agent did for a user cannot stitch two consoles together after the fact. Without an owner, an agent's credentials outlive the project that created it in the same way a contractor's account outlives the contract. The workloads that run inside cloud accounts are a different matter. They authenticate with the cloud provider's own workload identity and are governed with CIEM and workload and machine identity management, which an IDaaS platform does not replace.