Users And Login Methods¶
Use this page when your business team needs to decide who can sign in and which methods they should use.
What You Configure¶
In SigID, a business team usually configures:
- who can access a workspace or app
- whether users are invited, approved, or allowed to self-serve
- which sign-in methods are available
- whether MFA or fresh verification is required for sensitive actions
- what recovery or support path users should follow
- whether some organizations must use SSO
Choose Sign-In Methods¶
Apply the table to each candidate: passkeys for a strong default that reduces phishing risk, email and password as a familiar fallback, magic link for low-friction email sign-in, MFA or fresh verification when sensitive actions need another proof, SSO when a company or customer wants its own identity provider.
Before enabling a method, get the admin to answer its support question - passkey on another device, safe password reset, expired or delayed magic link, lost MFA device, or who owns domain, role, and identity-provider problems.
Do not enable any method whose support question is unanswered.
| Method | Use it when | Support question to answer |
|---|---|---|
| Passkeys | You want a strong default that reduces phishing risk. | What should users do when a passkey is on another device? |
| Email and password | Users expect a familiar fallback. | How do users reset passwords safely? |
| Magic link | You want low-friction email-based sign-in. | What should users do when a link expires or email is delayed? |
| MFA or fresh verification | Sensitive actions need another proof. | What happens if the user loses the MFA device? |
| SSO | A company or customer wants users to sign in with its identity provider. | Who owns domain, role, and identity-provider problems? |
Invite And Test Users¶
Before broad invites, complete all six steps: verify the email list, decide whether users can self-serve or need approval, test at least one invite end-to-end, confirm what the first sign-in prompt says, confirm support can answer passkey, password, magic-link, MFA, and SSO questions, and document what users should do if sign-in fails.
The self-serve-versus-approval decision belongs to the admin - ask before configuring it.
If the end-to-end test invite fails, fix the cause before sending any further invites.
Before sending broad invites:
- Verify the email list.
- Decide whether users can self-serve or need approval.
- Test at least one invite end-to-end.
- Confirm what the first sign-in prompt says.
- Confirm support knows how to answer passkey, password, magic-link, MFA, and SSO questions.
- Document what users should do if sign-in fails.
What Users Need To Understand¶
Prepare user-facing guidance covering all six points: start from the app rather than a random SigID page, SigID is the sign-in and account-security step for that app, choose the method shown on the page, passkeys are usually the safest option when available, never approve prompts they did not start, and contact the app or workspace support channel when recovery fails.
Have the admin review the draft and confirm the support channel it names is correct.
Verify this guidance reaches users before broad invites go out.
Users should know:
- they should start from the app, not from a random SigID page
- SigID is the sign-in and account-security step for that app
- they should choose the method shown on the page
- passkeys are usually the safest option when available
- they should not approve prompts they did not start
- they should contact the app or workspace support channel when recovery fails
For enterprise customers, continue to Organizations And SSO.