Short answer: yes. When you enable SSO for a Prefect Cloud account, existing users are linked to their SSO identity on first SSO sign-in as long as the IdP sends the same primary email address the user already uses in Prefect Cloud. There’s no separate “conversion” step required. Key details and caveats: - Matching/linking: It’s email-based. If the IdP sends a different email (alias, different domain, plus-addressing), Prefect will treat it as a new user. To avoid duplicates, ensure the IdP’s NameID/subject or email claim matches each user’s Prefect primary email. - Enforce SSO: You can enable SSO first, test with a pilot group, then turn on “Enforce SSO” to disable password-based login. Existing API keys continue to work until you rotate/revoke them; many teams rotate keys after enforcing SSO. - SCIM (Enterprise): If you enable SCIM after SSO, users will be matched by email and then managed by your IdP going forward (provision, deprovision, role updates). SCIM won’t retro-delete users unless deprovisioned in the IdP. - Duplicates: If a duplicate user does get created due to a mismatched email, an account admin can remove the unneeded user. If you need a merge, contact Prefect Support. If helpful, I can share a step-by-step checklist tailored to your IdP. Which provider are you planning to use (Okta, Azure AD, Google, OneLogin, etc.), and do you plan to enforce SSO immediately or phase it in?

Short answer: not in a single account. In Prefect Cloud, SSO is enforced at the account level. Once you complete SSO configuration, interactive user logins for that account go through your IdP (Okta) only—password/Google auth cannot remain in parallel. Your reading of the docs is correct: after configuration, users must authenticate via the IdP. That said, you can do a phased migration without service interruption by prepping users and automation before the cutover: Recommended phased approach - Map users ahead of time - Cohort 1 (same domain): Ensure their Okta profile’s primary email matches their Prefect user email. On first Okta sign-in, they’ll be linked automatically. - Cohort 2 (Google, different domain): Before enabling SSO, invite their Okta-backed company-domain email to the same Prefect Cloud account and assign roles/teams. Have them accept the invite and confirm access while Google auth is still active. After cutover, they’ll sign in via Okta with the new email. You can later remove the old Google-auth user. - If some users won’t exist in Okta (e.g., contractors), they will not be able to log in post-SSO unless you add them to Okta or keep them on a separate account temporarily. - Protect automation and workers - Programmatic access via API keys is not gated by SSO, so running flows/workers won’t be interrupted. Still, it’s a best practice to migrate automation to service accounts (with their own API keys) before cutover, then rotate user keys after. - Links: Service accounts, API keys - Test before you flip the switch - If you want to validate the Okta integration without impacting your production account, set up a sandbox Prefect Cloud account/workspace, integrate Okta there, and run a pilot. - If you’re Enterprise and plan to use SCIM for automated provisioning/deprovisioning, coordinate SCIM rollout after SSO. Email matching still applies. Overview: Manage users overview - Cutover - Schedule a short window to configure Okta SSO on your production account. - After SSO is configured, all interactive logins go through Okta. Any duplicate users created due to email mismatches can be cleaned up by an account admin. Key docs - Configure SSO - Manage teams - API keys - Service accounts - Manage users overview If you prefer a true “side-by-side” period where Google and Okta logins both work, the practical way is to run two Prefect Cloud accounts in parallel for a short time: keep the current account as-is while you bring up a new account with Okta SSO enabled, migrate users and workloads, then decommission the old one. Would you like a concrete checklist tailored to your Okta setup? Also, are you planning to use SCIM, and do your Google-domain users have company-domain identities in Okta yet?

Short answer: yes. API keys are bound to a specific user (or service account) and do not transfer. If Cohort 2 users get new Prefect users with the company domain, they’ll need to create new API keys for that new identity. What happens to the old keys: - Existing keys tied to the old Google-auth user will continue to work after SSO is enabled until you revoke them or remove that user from the account. - However, those users won’t be able to sign in to manage those keys once SSO is enforced (since their Google identity won’t work), so plan rotation before cutover or have an admin remove the old user when you’re done with the transition. Best practice to avoid interruptions: - Migrate automations off personal user keys to service accounts before cutover. Service account keys are not impacted by SSO and can be rotated on your schedule. - After cutover, users who need personal CLI access should create fresh keys under their new company-domain Prefect user. Docs: - API keys - Service accounts If helpful, I can share a short rotation checklist to move running workers/CI from personal keys to service accounts ahead of the SSO switch.

Short answer: there isn’t a self-serve way in Prefect Cloud today to “rename” a user’s email. The supported path is to invite the new company-domain email as a new user, assign the same roles/teams, and then retire the old Google-auth user. That does mean new personal API keys for that new identity. Ways to minimize impact - Keep workloads running while you migrate: - Existing API keys tied to the old Google-auth user will continue to work until you revoke them or remove that user. Use this window to rotate credentials. - Migrate automations to service accounts first so nothing breaks when people switch identities. Service accounts and their keys are not affected by SSO. Docs: Service accounts, API keys - Pre-provision and test: - Invite the new company-domain emails to your account, assign the same teams/roles, and have users verify CLI/UI access before enabling Okta SSO. After SSO is enabled, they’ll sign in via Okta and continue working with their new personal keys. - Clean-up: - After cutover and key rotation, remove the old Google-auth users to avoid confusion. If your goal is to avoid issuing new keys entirely - Please reach out to Prefect Support. For Enterprise accounts, our team may be able to advise on options for backend user email updates. If a backend email update is performed (keeping the same user record), existing API keys and workspace memberships would remain intact because the underlying user identity doesn’t change. We’ll confirm feasibility and next steps for your account. Contact: Prefect Support Related docs - Configure SSO (Okta) - Manage users overview If you’d like, I can draft a step-by-step cutover plan (including service account setup and key rotation) tailored to your Okta rollout and team structure. Are you on the Enterprise tier, and do you want me to loop in Support for guidance on potential email updates?

Great question — here’s a concise checklist of things to watch for when moving users to new company-domain identities. Access and RBAC - Recreate roles and memberships: Re-assign Account role (Admin/Member), Workspace memberships, and Teams for each new user so they retain the same permissions. Link: Manage teams - Seat count during overlap: You’ll briefly have both old and new users active; plan for temporary extra seats until cleanup. API keys and automation - Personal API keys don’t transfer: New users need new keys; rotate before cutover. Link: API keys - CI/workers/webhooks: Update any CI secrets, workers, or scripts that used personal keys. Best practice: migrate these to service accounts first to avoid disruption. Link: Service accounts - Running flows: Existing runs aren’t impacted by a user switch, but future automation/CLI operations that used old keys will fail once you revoke/remove the old user. Objects and ownership - Workspace objects: Flows, deployments, work pools, automations, and blocks are workspace-scoped, not user-owned, so they will continue to exist. However, users need the same roles to manage them after the switch. - Credentials/blocks: If any blocks use personal credentials (e.g., a user’s PAT/keys), rotate those to organization-managed credentials to avoid hidden dependencies on the old user. Notifications and preferences - Notification recipients: If you target specific user emails in notifications, update those to the new addresses or use team-based channels (e.g., Slack webhooks). - Personal UI settings: Any user-specific preferences (e.g., notification settings) will need to be reconfigured by the new user. SSO/Okta specifics - Attribute mapping: Ensure Okta sends the correct email as the NameID/primary email so users link cleanly when they sign in. Link: Configure SSO - App assignment: Make sure each new user (or their Okta group) is assigned to the Prefect app in Okta before cutover. - SCIM (if applicable): If you’ll use SCIM, coordinate group and role mapping and confirm email matching ahead of time. Overview: Manage users overview Operational considerations - Local environments: Users must replace any locally stored tokens/env vars (e.g., PREFECT_API_KEY) with their new key. Ask them to re-auth:

prefect cloud login --key <NEW_KEY>

. - Auditing: Historical actions will remain attributed to the old user; that’s expected. Keep the old user around temporarily (without keys) if you need short-term traceability, then remove. - Bookmarks/sign-in path: After SSO, all logins go through Okta. Make sure users know to use the Okta tile or SSO flow. Optional safety net - Parallel accounts: If you need true side-by-side auth for a short window, some teams spin up a separate Prefect Cloud account with Okta enabled and migrate workloads, then decommission the original. This isn’t required but can reduce perceived risk. If you want, I can turn this into a concrete migration plan for your team, including: - Service account setup and key rotation sequence - Role/team mapping checklist - Okta attribute and app assignment checklist - Timeline and communications template for users Do you plan to use SCIM with Okta, and do you currently have any workers or CI using personal user keys we should target first?

Thanks for calling that out — my wording was imprecise. In Prefect Cloud there is no separate “enforce SSO” toggle. Once you configure SSO for an account, SSO is immediately enforced for interactive logins to that account. Password-based and Google logins stop working for that account’s users. That’s exactly what the docs mean by “users must authenticate through your identity provider.” Link: Configure SSO What you can still phase: - Programmatic access: API keys continue to work after SSO is enabled (they’re not gated by SSO). This lets your workers/CI keep running while you rotate credentials. Links: API keys, Service accounts - User migration prep: You can pre-invite and permission new company-domain users before the cutover so they’re ready to sign in via Okta once SSO is turned on. If you need to pilot the IdP setup without affecting production, the practical route is to use a separate sandbox Prefect Cloud account to validate Okta, then enable SSO on the production account during a planned cutover. Sorry for the confusion earlier. If you’d like, I can outline a concrete cutover plan (prep, service-account migration, user comms, and post-cutover cleanup) tailored to your Okta setup.

Awesome — here’s a concrete, low-risk cutover plan for Okta SSO with phased user migration, minimizing downtime and surprises. I’ve split it into phases with clear owner actions, user comms, and validation steps. Assumptions - You’ll enable Okta SSO at the account level (SSO is enforced immediately once configured). - You have two cohorts: - Cohort 1: existing users with your company domain - Cohort 2: existing Google-auth users with a different domain who need to switch to company-domain identities - You’ll move any automation off personal keys to service accounts before cutover. - Optional: You may later enable SCIM for provisioning, but it’s not required for this cutover. Phase 0 — Planning and inventory (T-2 weeks) - Owners: Cloud admin + Okta admin - Inventory all access and credentials: - People: list users, their current email domain, and which workspaces/teams/roles they need - Automation: list every place a Prefect API key is used (workers/agents, CI/CD jobs, scripts, notebooks, local dev) - Decide your SSO protocol in Okta: - OIDC or SAML 2.0 (both supported; SAML is Enterprise) - Ensure the IdP sends the user’s primary email as the email attribute that Prefect will use for matching - Prepare service accounts for automation: - Create service accounts per environment/team and generate API keys (store in your secret manager) - Migrate any workers/CI to use service account keys instead of personal keys; validate - Docs: Service accounts, API keys - Prep roles and teams: - Review teams and roles so the new identities get the same permissions - Docs: Manage teams Phase 1 — Pre-provision users and test access (T-10 to T-7 days) - Owners: Cloud admin - Cohort 1 (same domain): - Confirm their Okta profile email exactly matches their Prefect email (case-insensitive, but avoid aliases/plus-addressing) - Cohort 2 (Google/different domain): - Invite each user’s new company-domain email to your current Prefect Cloud account; assign the same teams/roles - Ask them to sign in using that new email (pre-SSO they can set a password) and create a new personal API key - Have them switch local CLI/automation to that new key - CLI login:

prefect cloud login --key <NEW_PERSONAL_API_KEY>

Verified help for this command: run

prefect cloud login --help

- Validation: - Confirm new identities can access the correct workspaces and operate deployments - Confirm automation is running under service accounts, not personal keys Phase 2 — Okta integration readiness (T-7 to T-3 days) - Owners: Okta admin + Cloud admin - Okta app setup: - Create the Prefect app in Okta (OIDC or SAML) - Map email attribute to the user’s primary email - Assign test users/groups to the app in Okta - Dry run in a sandbox: - If possible, validate Okta SSO in a separate sandbox Prefect Cloud account to confirm attributes and group assignment - Communication prep: - Draft and circulate cutover comms (see template below) Phase 3 — Cutover day (T-0) - Owners: Cloud admin + Okta admin - Final checks: - All automations use service accounts or the new company-domain personal keys - Cohort 2 has successfully tested new accounts - Okta app assignments are correct - Enable SSO on your production Prefect Cloud account: - Follow the doc: Configure SSO - Note: After this, interactive login is only via Okta for this account - Post-enable smoke test: - Sign in via Okta with a test user from each cohort - Trigger a test deployment and confirm runs complete - Verify workers/CI keep running (service accounts unaffected by SSO) Phase 4 — Post-cutover cleanup (T+1 to T+7 days)

- Owners: Cloud admin - Remove old access: - Revoke remaining personal keys tied to old Google-auth users (after confirming all migrations) - Remove old Google-auth users from the account to reduce confusion - Fix stragglers: - Update any lingering notifications that reference old emails - Revisit any blocks/credentials that may still reference personal secrets; rotate to org-managed credentials - Optional: SCIM rollout (Enterprise) - If you plan to use SCIM, enable it now that SSO is working, and connect Okta groups to Prefect. Verify email matching and role mappings - Manage users overview: Manage users overview User communication templates 1) Pre-cutover notice (T-5 days) - Subject: Action required: Prefect moving to Okta SSO on <date> - Body: - We’re moving Prefect Cloud login to Okta SSO on <date>. - Cohort 1 (company-domain emails): No changes needed, but ensure you can log into Okta and see the Prefect app. - Cohort 2 (non-company emails): You’ll receive an invite to Prefect with your company email. Please: - Log into Prefect using that new email before <date> - Create a new Prefect personal API key - Update your local CLI/automation to use the new key:

prefect cloud login --key <NEW_PERSONAL_API_KEY>

- Confirm you can access your usual workspaces - Automation: We are moving all automation to service accounts; no user action needed if you don’t run workers/CI - After <date>, all logins must use Okta; old Google logins won’t work 2) Cutover confirmation (T-0) - Subject: Okta SSO is now enabled for Prefect - Body: - You must sign in via Okta to access Prefect - If you see access issues, contact <internal support contact> - Automation remains unaffected; report any anomalies 3) Cleanup reminder (T+3) - Subject: Finalizing Prefect migration — remove old access - Body: - We will remove old Google-auth users and revoke remaining old keys on <date> - If you still need to copy any settings or rotate any local credentials, please do so now Key points and gotchas - SSO enforcement: Once configured, SSO is immediately required for interactive login - Email matching: Okta must provide the same primary email your users have in Prefect (for Cohort 1). Avoid aliases/plus addressing - Keys don’t transfer between identities: Cohort 2 will generate new personal keys; service accounts avoid downtime - Objects aren’t user-owned: Flows, deployments, work pools, and automations persist; just ensure the new users have the right roles - Temporary double seats: You’ll temporarily have old and new users; plan for seat count during overlap Useful docs - Configure SSO (Okta): Configure SSO - Manage teams and roles: Manage teams - Service accounts: Service accounts - API keys: API keys Open questions to tailor further - Will you use OIDC or SAML in Okta? Any SCIM plans? - Do you have contractors who won’t be in Okta but still need access? - How many workers/CI jobs currently use personal keys that we should target first? - Do you want me to draft the exact Okta attribute mapping checklist (based on your chosen protocol) and a more detailed comms playbook?

Great question. “Bypass SSO” is a special, break-glass capability granted only to Account Owners. What it means - Only Account Owners can sign in to the Prefect Cloud UI using Prefect’s native authentication even when SSO is enabled for the account. This is intended for recovery/admin use (e.g., IdP outage or misconfiguration), so you don’t lock yourself out of the account. - It does not apply to Admins or Members; they must use the IdP once SSO is configured. - It does not create mixed-mode login for everyone; it’s an exception strictly for Account Owners. - Programmatic access via API keys is unchanged by SSO. Service accounts and user API keys continue to work until rotated/revoked. Answering your cohorts question directly - No — existing non-owner users from either cohort will not be able to sign in without Okta once SSO is enabled. - Only designated Account Owners can bypass SSO. Everyone else must authenticate via Okta. Recommendations before you enable SSO - Keep the Owner list small and intentional: have at least two trusted Account Owners for redundancy. - Verify Owner access: ensure those Owners can use Prefect’s native login path (not Google or Okta) before the cutover. If you’re unsure whether your current Owners can do this, please contact Support to confirm your setup. - Document recovery steps: store recovery credentials in a secure vault and define who is responsible for break-glass access. References - Manage roles (Owner permission includes “Bypass SSO”): Manage roles - SSO behavior once configured: Configure SSO - Service accounts and API keys (unaffected by SSO): Service accounts, API keys If you’d like, I can review your current Account Owners and suggest a minimal, resilient owner set and a recovery runbook tailored to your Okta rollout.

Short answer: there isn’t a self-serve “disable SSO” toggle. If you need to roll back, you’ll need Prefect Support to remove the SSO configuration for your account. After SSO is removed, users can sign in again using the previous method (native/Google), and API keys/service accounts continue to work throughout. What this means in practice - While SSO is enabled: - Only Account Owners can bypass SSO for UI access (break-glass). Admins/Members must use Okta. Docs: Manage roles, Configure SSO - Programmatic access (workers/CI) using API keys is unaffected. - If you decide to roll back: - Contact Support to remove the SSO config: Prefect Support. Once removed, users can log in via the prior method again. - Any new company-domain users you created for Cohort 2 remain as separate users; if you want to consolidate identities, you’ll need to manage cleanup (remove duplicates, confirm which identity is primary). - API keys remain tied to the user/service account that created them; they’re not revoked by SSO removal. Suggested rollback/runbook - Before cutover: - Ensure at least two trusted Account Owners can bypass SSO (verify they can use native Prefect login). - Move automation to service accounts to avoid user-login dependency. - If issues occur at cutover: 1) Use Owner bypass to access the UI and pause user changes. 2) Check Okta attribute mapping (make sure the email sent by Okta matches Prefect users). 3) If necessary, ask Prefect Support to remove the SSO configuration to restore prior login flows. 4) Communicate to users to log in the old way; clean up any duplicate users created during testing/cutover. If you’d like, I can open a support ticket on your behalf or draft a rollback playbook for your team’s specific roles and users.

Short answer: no. In Prefect Cloud 3, account Owners can always bypass SSO by design, and there isn’t a setting to force Owners through SSO. - The Owner role explicitly includes “Bypass SSO,” while Admins and Members cannot bypass SSO and must use SSO when it’s configured. See Manage account roles. - SSO setup details: Configure SSO. Common approaches: - Keep the number of Owners to a minimum (one or two “break-glass” Owners). - Make everyone else Admins or Members so SSO is enforced. - If on Enterprise, use directory sync/SCIM to control provisioning and deprovisioning via your IdP. If stricter enforcement for Owners is a hard requirement, I can log it as a feature request for the team.

Thanks for the clear feedback — I completely understand the concern. I’ve created a feature request to: - Allow enforcing SSO for Owners (remove Owner bypass), and - Optionally disable email/password and magic-link logins account-wide, with notes about using support-based break-glass instead. You can follow and add context here: Feature request: Enforce SSO for Owners and disable magic-link/password bypass in Prefect Cloud 3. If you’re open to it, I can also share this internally with the product team and link your account/org so they understand the priority.