Stable

Passkeys and MFA before private app access

Use TOTP and WebAuthn passkeys for account security, passkey-first sign-in and fresh verification before private app launch.

Steps

Follow these in order.

  1. 01Verify the person, not only the browser sessionBefore a sensitive private app opens, BusinessProxy can ask for a recent TOTP or passkey assertion. The backend validates that the factor belongs to the user and that the assertion has not expired.
  2. 02Portal, branded app pages and mobile launchThe same MFA primitives support account setup, passkey login, private app launch from the web portal and mobile private-app launch.
  3. 03Strong factors are live; broad policy enforcement is nextPasskeys and TOTP are available for sign-in and fresh verification before app launch. Organization-wide MFA requirements and step-up for sensitive admin actions belong to the next enterprise policy layer.

Reference

Implementation details for setup and review.

Strong verificationUsers can register a passkey, sign in without typing a password and re-verify before opening a private app. The confirmation is short-lived, so an open browser session does not become indefinite app access.
  • WebAuthn/passkey registration
  • Discoverable passkey login
  • TOTP authenticator codes
  • Fresh app-launch assertion
Verify the person, not only the browser sessionBefore a sensitive private app opens, BusinessProxy can ask for a recent TOTP or passkey assertion. The backend validates that the factor belongs to the user and that the assertion has not expired.
  • Face ID, Touch ID, Windows Hello: Passkeys use the platform authenticator or password manager selected by the user and browser.
  • Authenticator code fallback: TOTP can be used as a practical factor where passkeys are not yet rolled out to every user.
  • Short-lived assertion: The app launch receives a time-limited assertion token instead of reusing the account password.
Portal, branded app pages and mobile launchThe same MFA primitives support account setup, passkey login, private app launch from the web portal and mobile private-app launch.
  • Passkey setup includes user verification.
  • Branded app domains use their own WebAuthn RP ID.
  • Expired or invalid MFA assertions fail closed.
  • The user sees action-focused copy: set up, verify and open.
Strong factors are live; broad policy enforcement is nextPasskeys and TOTP are available for sign-in and fresh verification before app launch. Organization-wide MFA requirements and step-up for sensitive admin actions belong to the next enterprise policy layer.
  • No absolute "phishing-proof" wording.
  • Device-posture checks are separate from MFA.
  • Workspace-wide MFA policy is still separate policy-layer work.