What is identity as a service (IDaaS) and what should you ask?

Identity as a service (IDaaS) is a cloud-hosted service that authenticates users and passes their identity to applications. It typically provides single sign-on, multi-factor authentication, a user directory and automated provisioning. You hand the identity provider role to someone else, so check standards support, recovery and exit terms.

What does IDaaS actually do?

Four functions cover most of it.

Authentication. The service checks who the person is: password, passkey, one time code or hardware key. NIST SP 800-63B sets the assurance levels for authenticators and the rules for secrets.

Single sign-on (SSO). After one sign-in, the person reaches many applications. Under the hood this uses a federation protocol. OpenID Connect adds an identity layer on top of OAuth 2.0, and the OpenID Foundation publishes the core specification. SAML 2.0 is the older XML based equivalent still common in enterprise software.

Provisioning. Creating, updating and removing accounts in each application as people join, move and leave. The SCIM protocol, defined in RFC 7644, exists for this. Without it, leavers keep accounts in tools nobody remembered to clean up.

Policy. Rules such as "require a hardware key for the finance app" or "block sign-ins from unmanaged devices".

Why do people outsource it?

Running an identity system well is hard. It has to be available all day, patched quickly, and tested against credential attacks. A specialist team can do that more consistently than a small IT group. The trade is concentration: one service now sits in front of everything.

What are the risks?

• Single point of failure. If the service is down or misconfigured, nobody signs in.
• Single point of compromise. An attacker who takes over an administrator account at the identity provider may be able to reach every connected application.
• Weak recovery. Account recovery is often the easiest path around strong authentication.
• Lock in. Exporting users, groups and policies may be slow or incomplete.

A constructed example

A 300 person company moves to IDaaS and connects 40 applications through OIDC and SAML. Six months later, an audit asks who has access to the finance system. Because provisioning uses SCIM from the HR system, the answer comes from one report. Two contractors still have accounts: the contract ended but the end date was never entered in HR. The fix is a data fix, not a tool change, and the example shows why the quality of the source of truth decides the quality of the access review.

What does migration usually involve?

Plan it as a staged project. Begin with the directory: clean duplicate accounts and unclear groups first, since a tidy source makes everything downstream easier. Then connect low risk applications to learn the process, move to the important ones, and keep a rollback route for each. Tell users early about sign-in changes, because help desk volume spikes when MFA enrolment starts.

Keep a record of which applications still accept local passwords. They are the exceptions that undo the benefit.

How to check or apply this

1. List your applications and mark which support OIDC, SAML and SCIM. Plan for the rest.
2. Ask how administrator access to the identity service is protected. Phishing resistant authenticators for admins should be a baseline.
3. Ask how account recovery works and who can approve a reset.
4. Ask what logs you get, how long they are kept and how they reach your monitoring.
5. Ask how you would export users and policy if you left, and test it once.
6. Decide a break glass account that does not depend on the service, store its credentials offline and alert on any use.
7. Run an access review each quarter against the provisioning data.

Quick check

Sources

• NIST SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management
• OpenID Connect Core 1.0
• RFC 7644, System for Cross-domain Identity Management: Protocol

Last reviewed: 18 October 2026.