In one sentence
The auth policy decides how people sign in to your QFormance org — which methods are allowed, which email domains are accepted, and whether a fresh passkey confirmation is required on the highest-impact actions.
- The policy gates how, not what. Roles and permissions still decide what someone can do once they're in.
- Email-domain restriction applies to invitations and SSO sign-ins. An out-of-policy domain is rejected at the callback.
- Step-up confirmation lasts five minutes — within that window, further sensitive actions skip the prompt.
Allowed sign-in methods
Tick the methods your team is permitted to use:
| Method | Notes |
|---|---|
| Email + password | Legacy, on by default |
| Passkey | Passwordless via an enrolled credential — Touch ID, Face ID, hardware key |
| Google SSO | Workspace accounts |
| Microsoft SSO | Microsoft 365 / Entra ID accounts |
Leaving all four ticked = no restriction (the default for existing organizations). Untick to block. The save dialog warns if your policy would lock you out on the next page load.
Allowed email domains
Restrict invitations and SSO sign-ins to specific domains. Type a domain and press Add — chips appear to show what's whitelisted.
When the list is non-empty:
- Admin invitations are rejected if the email's domain isn't in the list ("acme.com is not in this organization's allowed email domains").
- SSO sign-ins from out-of-policy domains are rejected at the callback ("Your email domain isn't permitted to sign in to this organization").
- An empty list (the default) means any email domain is permitted.
Step-up: require a passkey to confirm sensitive actions
Turn this on and certain high-impact actions prompt for a fresh passkey confirmation:
- Approving any step on a document, or direct-publishing a patch revision
- Approving or closing an MOC
- Approving an Exemption
- Approving a JHA or FMEA
- Closing an NCR
- Closing a meeting
Click the action as normal. A small Confirm with your passkey modal appears. Tap your passkey — the action proceeds and the audit trail records the confirmation timestamp.
The five-minute confirmation window means a series of sensitive actions only prompts once. After five minutes, the next sensitive action prompts again.
The audit trail then shows "user X confirmed with passkey at HH:MM:SS" alongside each gated action — not just "user X's session was used".
Two-tier guard when you turn step-up on
Toggling Require passkey for approvals is the kind of change that can quietly lock people out of their work, so QFormance gates it twice before it lands.
Tier A — hard block. You can't enable the toggle if Passkey isn't in your Allowed sign-in methods. The save returns:
"Add 'Passkey' to allowed sign-in methods before requiring it for approvals — your org currently has Passkey disabled."
The reason is simple: requiring approvers to confirm with a method the org has disabled is a contradiction. Tick Passkey in the methods list, save, then come back and turn step-up on.
Tier B — soft warn with confirmation. If you're enabling the toggle for the first time and the org has any users named as approvers (in MOC / Exemption routing rules, JHA / FMEA / Document defaults, document approval routing, or active delegations) who haven't yet enrolled a passkey, the save pauses and shows a dialog:
"These N approvers will be locked out of their approval queues until they enroll a passkey: …names…"
Cancel, ask those people to enroll, then come back. Or click Continue — the policy saves, and the names of the warned-but-not-yet-enrolled approvers get written into the activity row alongside the policy change. The audit trail then shows that you were warned and proceeded anyway, so an auditor reading back can reconstruct what state the org was in at the moment of the change.
The check is conservative — it sweeps every routing surface and every active delegator, so a user who could conceivably be asked to approve is included.
What the approver sees if they have no passkey
If an approver who hasn't enrolled a passkey clicks an action that's now gated, the Confirm with your passkey modal opens, and the Confirm with passkey button surfaces an inline panel: "No passkey enrolled — add one in your profile first." with an Enroll a passkey now link that opens the user's profile in a new tab. After they enroll, they return to the original tab and click Confirm with passkey — the action proceeds.
The dead-end "go enrol and come back" friction is the friction Tier B is designed to surface up-front.
Audit trail
Every change to the auth policy is recorded in the org's activity log with the previous and new values, the admin who made the change, and the timestamp. Step-up confirmations are recorded similarly, with the device name of the credential that confirmed.
What the policy does not do
- It doesn't replace roles and permissions — those still gate what a user can do.
- It doesn't force existing members to re-enroll — switching to passkey-only means their next sign-in needs a passkey, not an immediate kick.
- It doesn't migrate calendar / Outlook integrations — those use separate OAuth flows on the user's profile page.