#Multi-Factor Authentication (MFA)

#Overview

Multi-factor authentication adds an extra layer of security to your AiDial portal account. Sign-in, authenticator setup, MFA challenge, and recovery-code entry are handled by AiDial's identity provider, while the portal checks that your account satisfies the required MFA policy before non-remediation protected pages and actions are available.

#Which Roles Require MFA?

When MFA is required for a session, the portal treats it as compliant only after MFA is enrolled and the current sign-in has satisfied the required challenge. A non-compliant customer session goes to Account → Security, a partner session to Settings, and an internal AiDial administrator/operator session to Profile.

#Supported Authentication Factors

AiDial Portal currently recognises these MFA factors for supported accounts and roles:

• totp: Time-based One-Time Password from a TOTP-compatible authenticator app.
• recovery_code: Provider-issued recovery code used during sign-in.
• email_otp: Email one-time code. This is policy-allowed for client_admin and partner_admin only, unless a trusted provider policy claim explicitly allows it for another role.
• sms_otp: SMS one-time code. Policy-allowed for client_admin and partner_admin only, gated by an organisation setting that is off by default. Internal staff (aidial_admin, aidial_operator) are hard-denied. AU phone numbers only at launch. See sms-otp.md for the customer-facing privacy notice and sub-processor disclosure.
• webauthn: Passkey or security key. Policy-allowed for client_admin, partner_admin, aidial_admin, and aidial_operator.

The portal reports factors allowed for your role separately from factors enrolled on your account.

The portal does not render its own authenticator QR code and does not validate TOTP, email OTP, SMS OTP, passkey, security-key, or recovery-code values directly. Those steps happen with the identity provider.

#Where MFA Settings Live

The MFA surface you see depends on your role.

The richer Settings > Profile & Security panel (MFA setup link, SMS factor card, passkey card, declare recovery-code regeneration, disable-launch action) is code that no customer role reaches today: client_admin requests to /settings?section=profile are redirected to /account, and client_manager / client_staff get a not-found response there because their Profile section moved to the Account shell.

#How to Enrol in MFA

1. Sign in to the portal: Use the normal portal sign-in page. If the current session requires MFA and is not compliant, the portal redirects you to the role-specific surface listed above.
2. Open MFA setup: Go to the surface for your role (see Where MFA Settings Live) and use the trusted provider link when it is available — the per-method action on Account > Security for customer roles, or Re-enrol on the internal Profile page. The link opens the trusted provider security page for your account. Partner accounts do not get a setup link; partner MFA is operations-managed.
3. Complete setup: For TOTP, passkeys/security keys, and recovery codes, follow the provider-hosted enrolment flow. SMS one-time code has no reachable enrolment card today (see SMS One-Time Code).
4. Refresh the portal status: Return to the portal and sign in again so it receives fresh OIDC MFA claims. Where shown, Refresh security status starts that flow for you.
5. Acknowledge recovery-code storage if prompted: After enrolment, re-enablement, or declared recovery-code regeneration, the portal may ask you to confirm that you stored the current recovery-code set.

#Recovery Codes

Recovery codes are managed by the identity provider, not generated or displayed by AiDial Portal. Use them from the provider sign-in flow if you lose access to your authenticator app.

The portal stores only non-secret lifecycle markers for recovery-code acknowledgements and reminders. It does not store raw recovery codes.

#Important Guidelines

• Store recovery codes securely: Save them in a password manager or print them and keep them in a secure location.
• Acknowledge storage in the portal when prompted: This records that you stored the current provider-issued set; it does not copy the codes into the portal.
• Review or regenerate codes in the provider: If a trusted provider management link is available, use it to review or regenerate recovery codes, then refresh the portal status.
• Respond to recovery-code reminders: If the portal detects a recovery-code sign-in, your security surface may remind you to review or regenerate your codes.
• Never send raw recovery codes to support: Support can guide recovery steps, but users and operators must not paste recovery-code values, authenticator seeds, one-time codes, session cookies, or bearer tokens into tickets or chat.

#Recovery & Lockout

#If You Lose Your Authenticator Device

1. Use a recovery code with the identity provider: During provider sign-in, use the recovery-code option if it is available for your account.
2. Review your recovery options: After signing in with a recovery code, the portal may show a reminder in Settings to review or regenerate recovery codes.
3. Set up a new authenticator device: Use the trusted provider management link from Settings when available, then refresh the portal status.

#If You Have Lost Both Your Authenticator and Recovery Codes

If you cannot access your authenticator app and have no remaining recovery codes:

1. Contact your organisation's administrator: They may be able to assist with account recovery through the identity provider's administrative tools.
2. Contact AiDial support: If your administrator is unable to help, contact help@aidial.com.au for further assistance.

The portal cannot bypass MFA on its own, reveal one-time codes, or reset MFA from an unauthenticated browser session. Account recovery is managed through the identity provider and authorised support processes.

#Disabling MFA

• Roles that require MFA (partner_admin, aidial_admin, aidial_operator) cannot disable MFA while assigned to that role.
• The disable-launch action is coded on the Settings > Profile & Security panel only, which customer roles are currently redirected away from, so no role reaches it through supported navigation. Where it does render, it appears only when MFA is not required for the role, the account is currently enrolled, the challenge state is known, and a trusted provider management URL is available.
• Account > Security and the internal Profile page do not offer a disable action. They link out to the trusted provider security page and record recovery-code acknowledgements. Remove the factor in the provider instead.
• The portal does not disable the factor directly. It records the launch request and opens the provider management flow in a new tab.
• After changing MFA in the provider, refresh the portal security status so the current session reflects the new state.

#Next Steps

• Understand your role and permissions
• Learn about session security
• Learn about signing in