Enable 2FA and SSO for your team
How to turn on two-factor sign-in per user, configure single sign-on at the org account, and handle recovery and lockout.
A password alone is not enough for a site that holds customer data, runs payments, or publishes to a real audience.
Two-factor authentication adds a second proof-of-identity step on top of the password.
Single sign-on takes that further — every team member signs in through one trusted identity provider, and the provider's policies travel with the account.
This page walks the full identity-hardening cycle.
Turning on 2FA for an individual user, rolling out SSO at the org account, generating recovery codes for the days when the second factor is unreachable, and recovering an account that is locked out.
What is this for?
Use this page when you need to tighten sign-in security for a single user or for an entire team.
The page covers two related but different controls.
2FA is per user — anyone with an SGEN account can turn it on for themselves.
SSO is per organization — an admin configures it once and the whole team signs in through it.
Both controls work alongside each other.
A user with SSO and 2FA both active goes through the SSO step first; the identity provider may then enforce its own second factor.
For a team running both controls in parallel, the operating posture is consistent — every sign-in carries the password (or the SSO equivalent) plus a second factor.
The Audit Log records each step so the team has a full record of how every sign-in was completed.
Good use cases
- A single operator wants to protect their account with a second factor before doing any further work in SGEN.
- An agency principal wants every team member's account on 2FA before the next quarter.
- An organization with an existing identity provider wants every SGEN sign-in to route through it.
- A new team member is joining and the org account is on SSO; the team needs to confirm the user provisions correctly.
- A team member has lost the device that holds their 2FA code and needs to recover access.
- A compliance review is coming up and the team needs every active member running 2FA or SSO before the review window.
- An incident post-mortem identified an at-risk account; the operator needs to rotate the password and the second factor in the same sitting.
What NOT to use this for
- Replacing per-site role configuration.
- Per-page access control.
- Audit trail of access events.
How this connects to other features
- Security — the broader site-security posture; 2FA and SSO are two of the levers it documents.
- Audit Log — every sign-in, 2FA challenge, and SSO event is recorded.
- SG-Admin Users — the per-site user surface where individual accounts and roles are managed.
- SG-Dashboard — the org-account surface where SSO is configured.
- Manage Multiple Sites — the org-account workflow, where SSO and per-site role assignment work together for an agency or multi-site team.
- Back up and Restore — identity events are recorded into the same Audit Log that backup-and-restore events appear in; a security incident review often touches both surfaces in one sitting.
Before you start
- For 2FA setup, you have an authenticator app installed on a phone or other device — any app that supports time-based one-time passwords works.
- For SSO setup, you are signed in as the org-account owner — only the owner can configure SSO.
- For lockout recovery, you have access to the email address on the account, or a second admin user who can perform a reset.
- For a new SSO rollout, the team is informed in advance.
- For a team-wide 2FA enforcement, the team's password-manager strategy is settled — every member needs a place to save their recovery codes before the requirement turns on.
- For any identity rollout that touches an org with active customer support, schedule the rollout for a quieter window so a recovery question does not collide with a customer-side request.
Where to find it
Two surfaces carry these controls.
Per-user 2FA lives at Account Settings → Security.
Any signed-in user reaches it from the avatar menu at the top right of any SGEN admin page.
Org-level SSO lives at SG-Dashboard → Org Settings → Identity.
Only the org-account owner sees the Identity surface; team members see the org Settings page without the Identity tab.
For an agency that manages many org accounts on behalf of clients, each client's org account carries its own Identity surface — there is no cross-org identity scope.
A change made in one org's Identity surface affects only that org.
A third related surface, the Audit Log, sits at per-site SG-Admin and at the org-level SG-Dashboard Activity view.
Every identity event flows into the log; review it after any rollout or recovery action to confirm the expected events appear.
Steps
The workflow has four parts — turn on 2FA for one user, generate recovery codes, configure SSO at the org account, and walk the lockout-recovery path. They are independent; do whichever applies to the situation in hand.
1. Enable 2FA for one user
Open the avatar menu at the top right.
Click Account Settings.
The Account Settings page opens.
Click Security in the left navigation.
Scroll to Two-Factor Authentication.
The current state is shown as Off or On.
If Off, click Turn On 2FA.
A panel opens with a QR code and a setup key.
Open the authenticator app on your phone and add a new account.
Scan the QR code, or type the setup key if the camera is not available.
The app shows a six-digit code that refreshes every 30 seconds.
Enter the current six-digit code from the app into the Verify Code field on the SGEN panel.
Click Verify.
If the code is correct, the panel updates to confirm 2FA is now on for the account.
From this point, every sign-in for this user asks for the six-digit code after the password.
The code comes from the authenticator app — SGEN does not send the code by SMS or email.
The Audit Log records the 2FA-enabled event with a timestamp and the actor.
A team lead reviewing onboarding can confirm the step happened by filtering the log to identity events for the new user.
2. Generate and store recovery codes
The same Security panel shows a Recovery Codes section once 2FA is on.
Click Generate Recovery Codes.
A panel opens with ten one-use codes.
Each code can replace the six-digit app code one time, for one sign-in.
After a recovery code is used, it is removed from the active set.
Copy the codes to a safe place — a password manager is the right home, not a sticky note next to the laptop.
Click Save and Close when stored.
Generate fresh codes any time the existing set feels stale, or after a recovery code is used.
Generating a new set invalidates the previous set; old codes stop working the moment new codes are generated.
A team password manager is the better home than a personal one for shared accounts.
For individual operator accounts, the personal vault is appropriate; for any account a team uses jointly, the team vault keeps the codes findable when the original setter is on vacation.
3. Configure SSO at the org account
Open SG-Dashboard.
Click Org Settings in the left navigation, then Identity.
The Identity page opens with the current sign-in posture — Password, Password + 2FA optional, or SSO.
Click Set Up SSO.
A panel opens with a protocol picker — the supported protocols are listed there; pick the one the identity provider uses.
The panel shows two values to copy into the identity provider — the Entity ID for SGEN and the Reply URL that the provider sends the response to.
Both are unique per org account.
Switch to the identity provider's admin console.
Create a new application using SGEN as the service provider.
Paste the Entity ID and Reply URL into the provider's configuration.
The provider returns its own values — typically the metadata URL, the certificate, and the issuer.
Return to the SGEN Identity page.
Paste the provider values into the matching fields on the panel.
Click Test Connection.
SGEN attempts a sign-in round-trip against the provider; the result shows on the page within a few seconds.
A green result confirms the wiring is correct.
Click Activate SSO.
A second confirmation appears, listing every team member on the org account and noting that password sign-in will be disabled for them.
Confirm.
From this point, every team member signs in through the identity provider; password sign-in returns a Use SSO to sign in message.
4. Recover a locked-out account
The recovery path depends on what is missing.
Two common cases.
Case A — user has the password but lost the 2FA device.
Sign in with the password.
When the 2FA prompt appears, click Use a Recovery Code under the code field.
Enter one of the recovery codes generated earlier.
The sign-in completes.
Open Account Settings → Security and reconfigure 2FA on a new device.
Generate a fresh set of recovery codes.
Case B — user has neither the 2FA device nor recovery codes.
A second admin on the same account performs the reset.
The second admin opens the admin → Users, finds the locked-out user, clicks the row action menu, selects Reset 2FA.
The user receives an email with a one-time reset link valid for 24 hours.
Following the link signs the user in once and opens the 2FA setup flow on a fresh device.
The user generates new recovery codes before leaving the Security panel.
For an SSO-protected account where the identity provider itself is unreachable, the recovery path involves the provider, not SGEN.
SGEN cannot bypass the provider for an SSO-enforced org.
Contact the provider's admin or follow the provider's documented break-glass procedure.
For a team that handles lockouts often, document the case-A and case-B paths in the team's operating runbook.
The runbook entry names the admin who performs the reset, the timeframe in which it should happen, and the post-reset verification step.
Documented runbooks turn a stressful lockout into a routine three-minute task.
What success looks like
A 2FA setup is complete when the Security panel shows 2FA is On, the authenticator app generates a fresh code every 30 seconds, ten recovery codes are stored in a password manager, and the next sign-in asks for the code after the password.
An SSO rollout is complete when the Identity page shows SSO active, every team member can sign in through the provider, password sign-in is disabled with a clear redirect message, and the Audit Log records SSO sign-in events.
A lockout recovery is complete when the user signs in, sees the Account Settings page, and has fresh 2FA and new recovery codes in place.
A healthy identity posture at the team level shows three additional signals.
Every active member has 2FA on (or the team is SSO-enforced).
The Audit Log shows recent sign-in events for each active member; long-quiet members get re-confirmed or offboarded.
No member is sitting on a stale set of recovery codes from a setup more than a year old.
What to do if it does not work
- Authenticator app code is rejected at first verify.
- Recovery codes do not work.
- SSO test connection returns an error.
- Team member cannot sign in after SSO activation.
- SSO works but the user lands without role.
- Recovery codes were generated but the panel does not show them.
- 2FA panel shows On but sign-in does not prompt for the code.
- SSO activated for the org but a single member sees the password sign-in form.
Examples
Example A — solo operator turning on 2FA before further work.
Single-site owner opens Account Settings → Security, clicks Turn On 2FA, scans the QR code with the authenticator app, verifies the six-digit code, generates ten recovery codes, and stores them in a password manager.
The next sign-in adds one step; the account is now protected against a leaked password.
Example B — agency rolling SSO across a fifteen-person team.
Agency principal coordinates with the identity-provider admin for a date.
On the day, the principal opens SG-Dashboard → Org Settings → Identity, sets up SSO with the provider, runs Test Connection, confirms the green result, and activates SSO.
Every team member receives a sign-in-through-SSO email.
The team signs in via SSO that morning.
The Audit Log shows fifteen SSO sign-in events; one team member needed a provider-side provisioning fix, which the provider admin resolved in under five minutes.
Example C — recovery after a lost phone.
Editor's phone is replaced overnight.
They sign in with the password, click Use a Recovery Code, and enter one of the codes from their password manager.
The sign-in completes.
They open Security, click Turn Off 2FA, then Turn On 2FA again to set up on the new phone, and generate a fresh set of recovery codes.
Total time under three minutes; no admin intervention needed.
Example D — admin-driven 2FA enforcement for a newly hired team.
An agency principal onboards five new editors at once.
Each editor signs up, signs in, and is required to turn on 2FA before reaching any site content.
The principal sends each editor a short walkthrough — the page in this document plus a screenshot of the avatar menu.
Within the onboarding hour every editor has 2FA active, ten recovery codes saved in the company password manager, and a first sign-in event recorded in the Audit Log.
The principal confirms by filtering the log to identity events for the new editors.
Example E — phased SSO migration that protects business continuity.
A larger team running thirty editors decides to roll out SSO without disrupting publishing schedules.
The owner configures SSO in test mode, runs Test Connection, confirms the green result, then activates SSO for a small pilot group of five editors first.
Those five sign in through the identity provider for a week; the team confirms the experience is solid.
The owner then expands the SSO scope to the rest of the team.
The Audit Log carries every step — the test, the pilot activation, the full rollout — so the team has a clean record of how the rollout went.
Plan for enterprise and large-team identity scenarios
A small team can run 2FA as an individual habit. A large team needs identity treated as an operating system.
Enforcement at scale
For an org account where every member should run 2FA, the org-account owner can require it.
Open SG-Dashboard → Org Settings → Identity → Sign-in Requirements.
Tick Require 2FA for every member.
Save.
From the next sign-in, any member without 2FA active is walked through setup before they reach any other page.
Members already running 2FA notice nothing.
Pair the requirement with a documented onboarding step.
The team's new-hire checklist names "turn on 2FA, save the ten recovery codes to the company password manager, confirm sign-in" as a Day 1 action.
The Audit Log carries the evidence; the principal reviews it once per onboarding cycle.
For SSO-enforced orgs the picture changes.
SSO sign-in routes through the identity provider, and the provider's 2FA policy carries the second factor.
The org account does not need its own 2FA requirement because the provider's policy is the second factor.
Confirm the provider's policy does require the second factor — an SSO that allows password-only is the same security posture as no 2FA at all.
Just-in-time provisioning
Just-in-time provisioning lets a new team member sign in through SSO without an org admin pre-creating the account.
On first successful SSO sign-in, SGEN creates the local account with a default role.
The team member lands signed-in, with the right per-site access if the identity provider is set up to include site claims in the response.
Two practical patterns.
First, the provider sends a default site claim that maps to a low-privilege role; the org admin then upgrades the role through Members.
Second, the provider sends a role claim that maps directly to the per-site role on first sign-in; nothing further is needed from the admin.
The second pattern is faster but requires the provider's group structure to mirror the SGEN site structure.
Document the choice in the team runbook.
Identity is one of the surfaces where small assumptions create large surprises six months later.
Recovery readiness drills
A team that has never run a recovery is a team that will run its first recovery during the actual emergency.
Schedule a 2FA recovery drill once per quarter.
Pick one editor, have them simulate a lost phone, walk the recovery path under timed observation.
The drill produces three results — a confirmation the path works, a refresh of the editor's recovery codes, and a small lesson the team writes into the runbook.
For SSO, the drill is provider-side.
Confirm the team knows the provider's break-glass path.
A provider outage is rare but not unheard of; the team that has rehearsed the path handles it in minutes rather than hours.
Reference — populated identity event rows
A populated set of identity events on an SGEN site, captured over a single onboarding hour. The shape is what appears in the Audit Log; the operator reads it to confirm each step ran.
| Timestamp (UTC) | Actor | Event | Result | Source |
|---|---|---|---|---|
| 2026-05-22 14:03 | ada@yourteam.com | user.sign_in (password) | Success | Admin UI |
| 2026-05-22 14:04 | ada@yourteam.com | two_factor.enabled | Success | Account Settings → Security |
| 2026-05-22 14:04 | ada@yourteam.com | recovery_codes.generated | 10 codes issued | Account Settings → Security |
| 2026-05-22 14:08 | grace@yourteam.com | user.sign_in (SSO) | Success | Identity provider — provider_okta_sgen |
| 2026-05-22 14:09 | grace@yourteam.com | user.first_sign_in | Account auto-provisioned, role Editor | SSO just-in-time |
| 2026-05-22 14:11 | alan@yourteam.com | two_factor.challenge_failed | Code rejected (clock drift) | Sign-in flow |
| 2026-05-22 14:12 | alan@yourteam.com | two_factor.challenge_passed | Success after device clock sync | Sign-in flow |
| 2026-05-22 14:18 | ada@yourteam.com (admin) | user.reset_2fa | Reset link emailed to margaret@yourteam.com | the admin → Users |
| 2026-05-22 14:25 | margaret@yourteam.com | two_factor.enabled (re-setup) | Success | Reset-link flow |
| 2026-05-22 14:26 | margaret@yourteam.com | recovery_codes.generated | 10 new codes issued | Account Settings → Security |
Reference — recovery codes populated example
Recovery codes are short, easy-to-paste strings. The format below is the shape every code carries — ten of these appear on the Recovery Codes panel at generation.
sgnteam-4b21-7e09sgnteam-9af3-c1d2sgnteam-2705-88besgnteam-1e6c-9bbdsgnteam-fa31-204asgnteam-7d50-c39esgnteam-08a1-bf72sgnteam-3c4f-e1a6sgnteam-95dd-7022sgnteam-b6e2-018fEach code is single-use. The first characters carry a site-scoped prefix so a code from one site does not collide with a code from a different site. Save the full list in the team password manager — the platform never shows the codes again after this panel closes.
Reference — SSO test connection result fields
The Test Connection panel returns a structured result. A green pass is the success state; the table below shows the fields the panel reports on a failed test so the operator knows which side to fix.
| Field | Healthy value | Common failure value |
|---|---|---|
| Provider reached | Yes | No — host unreachable |
| Issuer matches | Yes | No — provider issuer does not match configured value |
| Certificate valid | Yes | No — certificate expired YYYY-MM-DD |
| Signed response | Yes | No — provider returned unsigned response |
| Reply URL accepted | Yes | No — Reply URL does not match provider's registered value |
| Round-trip latency | Under 1.5 s | Slow — over 5 s (review provider load) |
| Test user attribute mapping | Email, name, role claim received | No role claim — assign default role on SGEN side |
Reference — sign-in posture matrix per team shape
A table that maps the team's identity posture to the controls to activate.
| Team shape | Sign-in posture | 2FA requirement | SSO | Recovery readiness |
|---|---|---|---|---|
| Solo operator | Password + 2FA | Self-managed | n/a | Personal vault |
| Small team (2-10) | Password + 2FA across the team | Per-user, recommended | Optional | Shared team vault for codes |
| Mid-team (10-30) | SSO if provider is in place | Provider enforces | Active | Provider-side recovery + SGEN reset path |
| Agency (multi-client) | SSO per org account | Provider enforces | Active per org | Documented break-glass per client |
| Enterprise (over 30 members) | SSO with strict provider 2FA | Provider enforces | Active, JIT provisioning | Quarterly drill + provider-side break-glass |
Common questions about 2FA and SSO
Does SGEN send 2FA codes by SMS or email?
No.
Codes come from a time-based authenticator app.
The platform does not implement SMS-based 2FA because of well-documented vulnerabilities with SIM swapping; authenticator apps are stronger and avoid the carrier dependency.
Can a team member use the same authenticator app for SGEN and other services?
Yes.
The authenticator app holds an entry per service; SGEN is one entry alongside any others.
Most apps display every entry on the same screen with a clear label, so picking the right code is straightforward.
What happens if the org-account owner loses their 2FA device?
The standard recovery path applies — sign in with the password, use a recovery code, reconfigure 2FA on a new device.
If the owner has neither device nor codes, the platform's account-recovery support path handles it.
Owners should treat their recovery codes with the same care as a domain registrar's two-factor backup; loss is recoverable but slower.
Can a single user mix SSO and password sign-in?
On an SSO-enforced org account, no — every member signs in through SSO and password sign-in is disabled at the org level.
On an org account with SSO available but not enforced, members can choose either path.
The Audit Log records which path was used on each sign-in.
Does SSO replace per-site role configuration?
SSO covers sign-in.
Per-site roles cover what a signed-in user can do.
Both are needed; SSO does not replace the per-site role surface.
The identity provider can carry role claims that map to SGEN roles, but the per-site assignment still happens on the SGEN side.
What identity-event detail appears in the Audit Log?
Every sign-in (password or SSO), sign-out, 2FA challenge, recovery-code use, SSO test, and SSO activation appears with the actor, the timestamp, the source surface, and the result.
For SSO sign-ins the entry also names the identity provider so the team can trace a sign-in back to the right provider configuration.