#Multi-Factor Authentication (MFA)
#Sign-in verification
Required verification and first-time authenticator setup happen on the Portal where you began, before business access. Eligible email is selected first with a masked verified destination; select Send code to request a code. Use another method lists only allowed alternatives. Opening the page or changing methods sends no code. Correct a refused code or explicitly request a new one. After setup, sign in again and complete the required verification. Use an already-issued recovery code when offered.
#Overview
Manage supported own sign-in methods at your existing security home. Native authentication verifies factors; the Portal enforces current role/assignment/session and required MFA before protected access. Enrollment, capability, actual received proof and a completed normal sign-in are separate facts.
#Role and surface
| Roles | Personal security home | Email configuration |
|---|---|---|
| Client Admin, Client Manager, Client Staff | Account > Security (/account?section=security) | Client Admin only, when current native authority allows |
| Partner Admin, Partner User | Own Settings > Profile at bare /settings | Partner Admin only, when current native authority allows |
| AiDial Admin, AiDial Operator | Internal Profile (/profile) | Unavailable; stronger-factor rules remain |
Partner Admin, AiDial Admin and AiDial Operator retain required MFA. Other roles follow their effective current policy. Required MFA is compliant only when enrollment and the current sign-in challenge satisfy policy. A recovery acknowledgment or status badge cannot complete it. Partner-selected-client and organisation/IP settings do not select another user's personal security.
#Supported methods and current configuration
- Password and authenticator app: existing native forms, explicit same-tab identity confirmation, deliberate submissions and fixed expiry. Authenticator setup remains available beside other factors, but cannot overwrite READY TOTP. Removal/replacement requires a usable permitted alternative and fresh strong native proof.
- Passkeys/security keys: complete own native list and exact removal; registration uses the existing code-bound native ceremony on
/auth/passkey, with browser WebAuthn, fresh normal sign-in and readback. The auth-domain RP and required UV remain unchanged. Keep old keys until actual browser/related-origin continuity is proven; local virtual-key checks do not prove it. No operator-held registration is invented. - Email one-time code: reused own enable/disable controls for current Client Admin/Partner Admin. Native verified email, policy, ownership and current proof decide availability. Enabling immediately enrolls current verified email, sends no setup code and does not prove authentication. The Portal consumes native send/resend/check explicitly; native delivery/expiry/attempt rules remain authoritative.
- SMS: supports initial phone setup, private possession verification, factor enable/disable, phone replacement/removal, resend and abandonment for eligible Client Admin/Partner Admin. Availability requires the SMS-specific native contract and current scope/policy. Every acknowledged step requires ordinary sign-in before readback/continuation. Keep an independent usable method; SMS alone cannot redirect its recipient. See SMS one-time codes. The editable profile mobile field does not configure SMS.
- Linked providers: supported local credentials remain available on linked accounts. Own unlink uses the full authoritative linked handle, proven local confirmation and native usable-login safeguards. No linking/replacement/account delegation engine is provided.
- Recovery: use another usable enrolled method or an already-issued code if normal sign-in offers it, then identity-verified administrator/AiDial support. Code issuance/regeneration is unavailable here. A reminder does not prove codes were issued.
Availability is per credential from authoritative native facts, policy and actual confirmation. It is never inferred from an email domain or a saved SSO configuration. Normal customer console/configuration links have been replaced by these controls or explicit support/unavailable states. Restricted operator recovery is a separate process.
#Authenticator setup and replacement
Confirm your own identity, read current status, then start and deliberately verify exactly six ASCII digits. Copy the full manual key into your app; the Portal stores no seed/code. I already added the pending key resumes existing setup without another Start, including when a READY-only native list cannot expose the pending seed. Restart requires separate confirmation. An additional setup means adding TOTP alongside another method; native permits one READY TOTP, so replacement first preserves/tests an alternative, removes current TOTP, obtains a fresh normal login and sets up the new app.
Expiry, cancellation and leaving clear local entry without native deletion or abort/replay. An uncertain write stays blocked across reads/expiry/login; a pending/empty list is not an operation receipt. Deterministic wrong-code rejection allows bounded deliberate correction. Known verification ends earlier logins, including the performer. Complete a fresh ordinary MFA login; enrollment alone does not unlock protected access.
#Passkey registration and resume
Current strong confirmation starts the existing secure-domain ceremony in the same tab. The server retains exact operation/code metadata transiently; only exact own READY-key readback after a newer validated same-subject normal login completes it. Callback navigation or a changed list cannot. The result returns to the originating Portal home.
Resume an unexpired pending ceremony through Resume this exact registration. Stopping locally, cancellation or expiry retains exact reconciliation custody; it never deletes old or new keys or permits blind retry. Lost/restarted transient state cannot fabricate completion; use fresh normal authentication/current inventory and verified support.
#Email contact continuation
The separate profile request/cancel/retry flow uses native SetMyEmail and the existing contact/status row. Strong recipient-bound Set authority expires after 300 seconds. Acknowledgment ends earlier Portal authority and sends the existing native verification code. Hosted normal login verifies the current pending address before final OIDC completion; the Portal has no code form or partial session.
After verified matching native readback and fresh normal authentication, explicitly keep the email or restore the original. Status reads preserve this choice. Restoration requires verifying the pending mailbox and obtaining fresh strong authentication, then Set-original, NEW original-mail verification, another ordinary login and explicit restoration readback. Old-mail MFA can succeed while pending but cannot waive current-email verification or constitute full login. Lost mailbox/proof/expired continuation uses identity-verified support; email/SMS-only proof cannot redirect its recipient. Local retry-sync never resends a code or Set.
#Recovery and result handling
Never share passwords, authenticator keys, codes, tokens or challenge screenshots with support. The sign-in card offers Forgot password? and, when permitted, Sign in with a passkey in one wrapping row. Credential cards, including reset, activation, verification and passkey registration, have no support link. If no usable method remains, contact your organisation administrator or help@aidial.com.au. The administrator verifies identity and the exact account/ticket before any separately approved native recovery operation. The Portal cannot reset another person's account or lower MFA policy.
Every acknowledged material native commit ends earlier logins, including the performer. Success is followed by sign-in required. Audit/session secondary failure is reported honestly and cannot authorize replay. Unknown outcomes require reconciliation before retry; another factor is never deleted automatically. Recovery storage/reminder acknowledgments are non-secret local markers, not code issuance or fresh proof.
#Related guides
The Portal cannot bypass MFA and does not store raw recovery codes.