---
summary: Business guide for deciding who can use SigID, how users sign in, when to use passkeys, passwords, magic links, MFA, and how to support recovery.
tags:
  - business
  - users
  - login-methods
  - mfa
categories:
  - For Business
---

# Users And Login Methods

<!-- agent:page
You are an AI agent helping a business team decide who can sign in to a SigID workspace or app and which sign-in methods to enable.
Ask up front: which workspace and app this covers, whether users are invited, approved, or allowed to self-serve, whether MFA or fresh verification is required for sensitive actions, whether some organizations must use SSO, and who owns recovery and support.
Work this page's flow: configure who can access the workspace or app, choose sign-in methods from the table (passkeys, email and password, magic link, MFA or fresh verification, SSO), then run the six-step "Invite And Test Users" sequence before sending broad invites. Configuration happens in the Dashboard at dashboard.sigid.org.
For every method you enable, get the matching support question answered first - for example what users do when a passkey is on another device, how passwords are reset safely, or what happens when a magic link expires.
Success: at least one invite tested end-to-end, support can answer questions for every enabled method, and the path users follow when sign-in fails is documented.
Pitfalls: enabling a method whose support question is unanswered, and users starting from a random SigID page instead of the real app.
Humans decide the access policy (self-serve versus approval) and own support; you prepare configuration, the test plan, and user-facing guidance.
-->

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

<!-- agent:action 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

<!-- agent:action 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:

1. Verify the email list.
2. Decide whether users can self-serve or need approval.
3. Test at least one invite end-to-end.
4. Confirm what the first sign-in prompt says.
5. Confirm support knows how to answer passkey, password, magic-link, MFA, and SSO questions.
6. Document what users should do if sign-in fails.

## What Users Need To Understand

<!-- agent:action Draft user guidance
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](organizations-sso.md).