Enable 2FA and SSO for your team
A password alone is not enough for a site that holds customer data or publishes to a real audience. SGEN gives you two independent identity controls: per-user two-factor authentication (2FA) and org-level single sign-on (SSO). Turn them on in the right order, store recovery codes before you need them, and know the lockout paths before an emergency — this guide covers all four workflows.
Two controls, one identity layer
2FA is per user — anyone on SGEN can enable it. SSO is per org — the owner wires it once and the whole team signs in through the provider. Both work in parallel.
Recovery codes before you need them
Ten one-use codes sit between a lost device and a full lockout. Generate and store them in a password manager at setup time — the platform never shows them again.
The Audit Log confirms every step
Every sign-in, 2FA challenge, recovery-code use, SSO test, and SSO activation is recorded in the Audit Log with actor, timestamp, and result.
Before you start
Gather what each workflow needs before you open a settings panel.
2FA Setup
What to have ready
An authenticator app installed on a phone or device — any app that supports time-based one-time passwords works. No other requirement.
SSO Setup
What to have ready
Be signed in as the org-account owner (only the owner sees the Identity tab) and have admin access to the identity provider.
Lockout Recovery
What to have ready
Access to the email address on the account, or a second admin who can perform a reset from the Users area.
New SSO Rollout
Warn the team first
Once SSO is enforced, password sign-in is disabled. Inform the team in advance — members without a working SSO link cannot sign in after activation.
Where to find the controls
Per-user 2FA and org-level SSO live on different surfaces. Know the location before the first click.
Per-user 2FA
Account Settings → Security — reach it from the avatar menu at the top right of any SGEN admin page.
Org-level SSO
SG-Dashboard → Org Settings → Identity — only the org-account owner sees the Identity tab. Each client org account carries its own Identity surface; there is no cross-org SSO scope.
Audit Log
Per-site SG-Admin and at the org-level SG-Dashboard Activity view. Every identity event flows into it; review after any rollout or recovery to confirm the expected events appear.
Enable 2FA for one user
2FA is per user. Walk through this once per account that needs a second factor. The setup takes under three minutes with an authenticator app in hand.
1
Open Account Settings → Security
Click the avatar menu at the top right of any SGEN admin page. Click Account Settings. The Account Settings page opens. Click Security in the left navigation.
2
Turn on 2FA
Scroll to Two-Factor Authentication. The current state shows as Off. Click Turn On 2FA. A panel opens with a QR code and a setup key.
3
Scan the QR code in the authenticator app
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.
4
Verify the code
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. From this point, every sign-in for this user asks for the six-digit code after the password. SGEN does not send the code by SMS or email.
Generate and store recovery codes
Recovery codes are the safety net behind the safety net. Generate them immediately after enabling 2FA — before closing the Security panel. The platform never shows them again after the generation step.
1
Open the Recovery Codes section
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.
2
Copy the codes to a password manager
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. A password manager is the right home — not a sticky note. For shared accounts, the team vault keeps the codes findable when the original setter is unavailable.
3
Save and close
Click Save and Close once the codes are 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 immediately.
Configure SSO at the org account
SSO routes every team member through one identity provider. The org-account owner configures it once. Run a test connection and confirm with the team before activating.
1
Open Org Settings → Identity
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.
2
Pick a protocol and copy the SGEN values
Click Set Up SSO. A panel opens with a protocol picker — 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.
3
Configure the identity provider
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.
4
Test the connection
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; the result shows on the page within a few seconds. A green result confirms the wiring is correct. Do not activate until the test passes.
5
Activate SSO
Click Activate SSO. A confirmation lists every team member and notes that password sign-in will be disabled. Confirm. From this point, every team member signs in through the identity provider; password sign-in returns a Use SSO to sign in message.
Recover a locked-out account
The recovery path depends on what is missing. Two common cases — know both before a user needs either.
Case A
User has the password, 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 stored recovery codes. The sign-in completes. Open Account Settings → Security, cycle 2FA off and on for the new device, and generate fresh recovery codes.
Case B
User has neither the 2FA device nor recovery codes
A second admin opens the admin → Users, finds the locked-out user, clicks the row action menu, and 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.
Heads up For an SSO-protected account where the identity provider itself is unreachable, recovery 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.
What success looks like
Use these states to confirm each workflow completed correctly before moving on.
2FA setup complete
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. The next sign-in asks for the code after the password.
SSO rollout complete
The Identity page shows SSO active. Every team member can sign in through the provider. Password sign-in shows a clear redirect message. The Audit Log records SSO sign-in events.
Lockout recovery complete
The user signs in, sees the Account Settings page, and has fresh 2FA configured plus new recovery codes stored in the password manager.
Troubleshooting
Common problems and the specific fix for each.
Authenticator app code is rejected at first verify
The phone's clock is out of sync with the SGEN server. Open the phone's date-and-time settings and turn on automatic time. Try the code again.
Recovery codes do not work
Either a newer set was generated and invalidated the old, or the codes were entered with copy-paste whitespace. Generate a fresh set if signed in, or use the Case B admin reset path if locked out.
SSO test connection returns an error
The error message names the failing field — common ones are wrong issuer, expired certificate, or unmatched Entity ID. Fix the named field and retry. Do not activate until every field shows the healthy value.
Team member cannot sign in after SSO activation
The user does not exist on the identity provider, or is not assigned to the SGEN application there. Provision the user on the provider. SGEN auto-creates the local account on first successful SSO sign-in if just-in-time provisioning is on.
SSO works but the user lands without a role
SGEN provisions the local account with a default role on first sign-in. Open the admin → Users and assign the correct role; the next sign-in lands the user with the new permissions.
Recovery codes panel does not show codes
The platform shows the codes once at generation time and never again — by design, they are stored in a form the platform cannot read back. Generate a fresh set, which invalidates the previous unsaved set and shows new codes one time.
2FA panel shows On but sign-in does not prompt for the code
A cached session may be skipping the prompt for the current browser. Sign out fully, close the browser, then sign back in. The 2FA prompt appears on the fresh session.
SSO activated but one member still sees the password form
The member's local account is re-keyed to SSO on the next sign-in attempt after activation. Have the member click Sign in with SSO rather than entering a password — the routing carries them through.
Enterprise and large-team identity
A small team can run 2FA as an individual habit. A large team needs identity treated as an operating system. Three areas scale differently.
Enforcement
Require 2FA for every member
The org-account owner can require 2FA org-wide at SG-Dashboard → Org Settings → Identity → Sign-in Requirements. Tick Require 2FA for every member and save. From the next sign-in, any member without 2FA active is walked through setup before reaching any other page. Members already running 2FA notice nothing. For SSO-enforced orgs, the provider's 2FA policy carries the second factor — confirm the provider does require it.
Provisioning
Just-in-time user provisioning
On first successful SSO sign-in, SGEN creates the local account with a default role. Two patterns: the provider sends a default site claim and the admin upgrades the role through Members; or the provider sends a role claim that maps directly to the per-site role on first sign-in. 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.
Drills
Recovery readiness drills
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 confirms the path works, refreshes the editor's recovery codes, and produces a lesson for the runbook. For SSO, confirm the team knows the provider's break-glass path — a provider outage is rare but the team that has rehearsed handles it in minutes.
Sign-in Matrix
Identity posture by team shape
Solo operator — Password + self-managed 2FA, personal vault for codes. Small team (2-10) — Password + 2FA per user, shared team vault. Mid-team (10-30) — SSO if a provider is in place, provider enforces 2FA. Agency (multi-client) — SSO per org account, documented break-glass per client. Enterprise (over 30) — SSO with strict provider 2FA, JIT provisioning, quarterly drills.
SSO attribute mapping reference
When you configure SAML 2.0 SSO, the SGEN SSO panel asks you to map identity provider attribute names to SGEN fields. Attribute names are case-sensitive and must match what the identity provider sends in the SAML assertion.
{ "email": "emailAddress", "first_name": "givenName", "last_name": "surname", "role": "sgenRoleClaim", "role_map": { "SiteAdmin": "platform_admin", "Editor": "editor", "Contributor": "content_editor", "Viewer": "viewer" }, "auto_provision": true, "default_role": "viewer", "exclude_accounts": [ "admin+breakglass@yoursite.com" ]}Illustrative mapping shape — confirm exact attribute names against the live SSO panel before enabling enforcement.
If the identity provider sends emailAddress but the SGEN mapping field expects email, the login fails with an attribute mapping error. Always test with a real identity provider user before enabling enforcement for all accounts.
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 you know which side to fix.
Provider reached
Healthy: Yes. Common failure: No — host unreachable.
Issuer matches
Healthy: Yes. Common failure: No — provider issuer does not match configured value.
Certificate valid
Healthy: Yes. Common failure: No — certificate expired. SAML certificates typically expire after one to three years; set a calendar reminder 60 days before expiry.
Signed response
Healthy: Yes. Common failure: No — provider returned unsigned response.
Reply URL accepted
Healthy: Yes. Common failure: No — Reply URL does not match the provider's registered value.
Test user attribute mapping
Healthy: Email, name, and role claim received. Common failure: No role claim — assign a default role on the SGEN side.
A failed field is the named fix. The panel does not move past a failed test; activate SSO only after every field shows the healthy value.
Ongoing security hygiene
Authentication hygiene degrades over time. A quarterly review and awareness of common mistakes keeps the identity posture sound.
Quarterly Review
What to check once per quarter
Check the Users list for accounts with password-only status and reset their enrollment if any pre-date 2FA enforcement. Check identity provider application assignments and remove former employees and test accounts. Verify the break-glass account can sign in — test it. Check the SSO certificate expiry date. Review the Activity Log for repeated failed logins, logins from unexpected regions, or a spike in 2FA reset requests. The review takes about 20 minutes; pair it with the monthly backup check to make it a single recurring task.
Anti-patterns
What not to do
Sharing 2FA codes — the code proves physical device possession; sharing defeats the second factor entirely. Create a separate account instead. Disabling 2FA "temporarily" — use the recovery code path or admin reset instead. Storing recovery codes alongside the password — keep them in a separate vault entry. Enabling SSO enforcement without a break-glass account — a misconfigured SSO with no fallback is a full lockout; test the break-glass account monthly. Skipping the grace period when enforcing 2FA — 14 days gives occasional users and people on leave time to set up an authenticator app.
Audit Log — identity event reference
Every identity action is recorded in the Audit Log. The table below shows the shape of events from a single onboarding hour — use it to confirm each step ran correctly after a rollout or recovery.
user.sign_in (password)
Records actor, timestamp, source (Admin UI), and result. Appears on every password sign-in.
two_factor.enabled
Records actor and timestamp at Account Settings → Security. Confirms 2FA setup completed for the account.
recovery_codes.generated
Records actor, timestamp, and quantity (10 codes issued). Appears immediately after clicking Generate Recovery Codes.
user.sign_in (SSO)
Records actor, timestamp, identity provider name, and result. The provider name lets the team trace a sign-in back to the right provider configuration.
user.first_sign_in
Records SSO just-in-time account creation — actor, role assigned (e.g. Editor), and source (SSO just-in-time).
two_factor.challenge_failed / two_factor.challenge_passed
Records failed and successful 2FA challenges at the sign-in flow. A failed challenge followed quickly by a passed one typically indicates a clock drift issue that self-corrected after device time sync.
user.reset_2fa
Records the admin who performed the reset, the target user, and the timestamp. The reset link is emailed to the locked-out user and is valid for 24 hours.
The same set of identity events, exported, becomes a one-page record an onboarding lead can hand to a compliance reviewer at quarter-end.
Common questions
Straight answers to the questions that come up most often when teams set up 2FA and SSO for the first time.
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.
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. Treat recovery codes with the same care as a domain registrar's two-factor backup.
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?
No. SSO covers sign-in. Per-site roles cover what a signed-in user can do. Both are needed. 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.