Skip to main content

Sign-in methods

Use Authentication > Sign-in Methods to decide how end users prove identity before entering your app.

Switera sign-in methods settings with email, phone, username, and password policy sections
Start with one primary sign-in method. Add more methods only when they improve the user experience or satisfy a customer requirement.

Choose the first method​

MethodGood fitWatch for
Email and passwordFamiliar sign-in with broad compatibility.Pair with email verification and a sensible password policy.
Email sign-in or magic linkLow-friction access where email ownership is enough.Requires reliable email delivery.
Passwordless codeMobile or lightweight account flows.Codes must expire quickly and be rate-limited.
PasskeysHigh security and low friction for supported users.Keep a fallback method for recovery.
Phone/SMSMobile-first products or phone-based identity.SMS delivery and number recycling risk.
UsernameApps where email should not be the primary identifier.Define length and character rules early.

Configure the baseline​

  1. Open Authentication > Sign-in Methods.
  2. Enable the primary method.
  3. Keep recovery enabled if users can lose access.
  4. Review email verification requirements.
  5. Review the password policy if password sign-in is enabled.
  6. Save.
  7. Test sign-up, sign-in, sign-out, recovery, and verification.

Password policy​

For a first production baseline, avoid both extremes. Do not allow weak passwords, but do not make policy so strict that users work around it.

Review:

  • minimum length
  • complexity requirements
  • breached or common password blocking if available
  • reset behavior
  • whether admins need step-up before password changes

Email verification​

Keep verification enabled for real users unless your product has a deliberate reason not to. Verification improves account recovery, invitation delivery, and support diagnosis.

Before launch, verify that:

  • the verification email is delivered
  • the link or code expires correctly
  • users can request another verification email
  • the template uses the correct app name and branding

Test checklist​

Use a test user and check:

  • registration succeeds
  • login succeeds
  • wrong password or invalid code shows a clear error
  • email verification is required or optional as expected
  • recovery works
  • the user lands in the correct app experience
  • audit logs record the configuration change

Related pages: