Set Up SSO, Passkeys, and User Provisioning

When this matters

This article is for organizations that need stronger identity controls than basic email and password access.

That usually includes:

• larger teams
• stricter security requirements
• centralized IT ownership
• planned SSO or SCIM rollout

Passkeys

Passkeys are designed to make sign-in more secure and more resistant to reused credentials.

In practice, teams should expect:

• registration and sign-in to happen as explicit browser ceremonies
• challenge responses to be short-lived and single-use
• users to complete the flow in one active session

If a passkey setup attempt is interrupted, start the sign-in or enrollment flow again instead of reusing stale prompts.

SSO domain verification

Before SSO can be enabled for a domain, the organization must prove control of that domain.

That typically means:

1. 01add the domain in settings
2. 02publish the verification DNS record
3. 03verify the record from the admin flow
4. 04enable SSO after verification succeeds

User provisioning expectations

If your team uses lifecycle-managed access, the important rule is simple:

• only provision users for the verified domain your organization controls

That keeps identity setup aligned with the organization boundary and reduces accidental account drift.

Before you turn identity features on

Make sure you know:

• who owns identity configuration
• which email domain is authoritative
• which users should remain local administrators
• how provisioning errors will be handled

Best practice

Roll out identity changes deliberately.

Start with:

• one verified domain
• a small pilot group
• a known admin owner
• a tested recovery path if someone loses access