Account recovery and authenticator readiness
Use this guide to plan account recovery with the available IDaaS capabilities. Account recovery includes the following:
- Password reset
- Help desk user verification
- User unlock
- First-time authenticator registration
- User Portal self-management
- Face Biometric recovery after Entrust Identity Verification
Recovery is a high-risk process. Configure recovery so that a user proves their identity with an appropriate authenticator before regaining access, resetting a password, or changing authenticators.
Recovery capabilities in IDaaS
IDaaS provides several capabilities that work together to support account recovery.
| Capability | What it does | Where to configure it |
|---|---|---|
| User registration | Requires users to register configured second-factor authenticators at first sign-in or when registration is required again. | User registration |
| Authenticator provisioning | Automatically creates or assigns selected authenticators for new users. | Configure authenticator provisioning |
| User verification | Requires users to verify identity before registration or authentication with external Identity Providers, Entrust Identity Verification, or both. | User verification |
| Entrust Identity Verification | Verifies users with government-issued ID and facial recognition, then creates a Face Authenticator after successful verification. | Set up Entrust Identity Verification |
| User profile registration and verification flags | Lets administrators require a specific user to complete registration or verification the next time they sign in. | Edit, delete, unlock, and disable users |
| Password reset | Lets users reset a forgotten password from the sign-in page after completing configured second-factor authentication. | Reset a password |
| Magic Links | Lets administrators send registration or password reset links when Magic Links are configured. | Magic Links solution guide |
| Temporary Access Codes | Provides short-term sign-in when users cannot access their primary authenticator. | Manage Temporary Access Codes |
| Help desk user verification | Lets an administrator verify a calling user with OTP, grid card, token, or token push before helping with recovery. | Require user verification |
| User unlock | Lets an administrator unlock users who are locked because of too many failed authentication attempts. | Edit, delete, unlock, and disable users |
| User Portal authenticator management | Lets users view and manage authenticators that administrators enable for User Portal self-service. | Configure authenticator policies |
| Authentication flows and resource rules | Determine which authenticators users can use for each application and risk outcome. | Create authentication flows |
| Group policies | Override global authenticator, registration, verification, and User Portal settings for selected groups. | Manage group policies |
| Bulk registration and verification | Lets administrators require or remove registration and verification for users or groups in bulk. | Bulk user registration and Bulk user verification |
| User notifications | Notifies users when contact information or authenticators change. | Manage user notifications |
Plan recovery before users need it
Configure recovery during onboarding so users have a reliable recovery path before they lose access to a password, device, or authenticator.
Automatic authenticator provisioning fits this recovery plan. When IDaaS creates a user account, it can automatically create or assign selected authenticators so the user has an initial recovery path before the first help desk request. Use automatic provisioning for authenticators that every user must receive, then use registration and User Portal policies for authenticators that users must enroll or maintain themselves.
Set up the following recovery capabilities during onboarding:
- Configure automatic authenticator provisioning for authenticators that every user must receive when the account is created.
- Enable user registration when users need to enroll authenticators during first sign-in.
- Set registration authenticators to Required, Optional, or Disabled based on your recovery model.
- Set Minimum Number of Second-factor Authenticators when users must enroll more than one authenticator before registration is complete.
- Enable user verification if users must verify identity before registration or authentication.
- If you use Entrust Identity Verification, configure Face Biometric settings before you enable verification.
- For individual users who need to re-establish registration or verification state, update the user profile so the user must complete registration or verification the next time they sign in.
- Use bulk registration or bulk verification when many users or groups must re-register authenticators or complete verification.
- Configure group policies when different populations need different registration, verification, authenticator, or User Portal recovery settings.
- Configure authentication flows and resource rules so recovery authenticators are allowed only where they match the application risk.
- Configure User Portal authenticator policies so users can maintain the authenticators that your recovery flows depend on.
- Enable user notifications when users must be notified about authenticator or contact information changes.
When you enable Entrust Identity Verification, successful verification sets the user status to Verified and creates a Face Authenticator for the user. You can then allow Face Biometric as a second factor for password recovery.
Configure password recovery carefully
Password reset lets users recover access without contacting an administrator. The user starts from the Forgot your password? link, enters a username, and completes the configured second-factor challenges before setting a new password.
When you configure password reset, consider the assurance of each allowed second-factor authenticator. IDaaS offers allowed second-factors in the order that you configure them. If the user does not have the first authenticator, IDaaS offers the next configured authenticator.
Use these controls for stronger password recovery:
- Put stronger authenticators earlier in the allowed second-factor list.
- Enable Additional second-factor when password recovery requires two second-factor challenges.
- Use Face Biometric as a password reset second factor after Entrust Identity Verification creates Face Authenticators for users.
- Restrict password reset to the groups that need it.
- Confirm that resource rules allow the password reset flow for the applications where users need recovery.
- Use password reset Magic Links only where email-based recovery matches your risk model.
Password reset is an account recovery flow. If you include lower-assurance authenticators such as email OTP, SMS OTP, voice OTP, Magic Link, or KBA, users who do not have a stronger listed authenticator might be able to reset passwords with those methods. Review the allowed second-factor list and group scope before enabling password reset broadly.
Use help desk verification before assisted recovery
When a user calls the help desk, administrators can use Verify from the user list before assisting with recovery. Currently, the verify user action supports OTP, grid card, token, and token push.
Use help desk verification when an administrator needs confidence that the caller is the account owner before taking recovery actions such as resetting a password, assigning a temporary access code, or changing authenticators.
For higher assurance in the current feature set, prefer token push when it is available because the user approves a push challenge in the registered token app. For OTP, grid card, and token responses, confirm that the user is using an authenticator already assigned to their account.
If the user cannot access their primary authenticator, an administrator can assign a Temporary Access Code as a short-term sign-in method. Configure the code lifetime and maximum uses so the code is limited to the recovery need.
Recover specific authenticators
Administrators can help users recover or replace some authenticators directly. Other authenticators require the user to complete registration or management from the User Portal after the administrator verifies the user or restores temporary access.
Before an administrator performs an account recovery or authenticator management action for a calling user, the administrator must verify that the caller is the account owner. Use the Verify action from the user list when the user has an available OTP, grid card, token, or token push authenticator. If the user cannot complete one of those methods, follow your organization's approved identity verification process before resetting a password, assigning a Temporary Access Code, sending activation material, deleting an authenticator, or requiring registration or verification again.
Administrators can also update a user so registration or verification is required the next time the user signs in. Use this when the user must re-register required authenticators, complete verification again, or return to the registration and verification flow after an assisted recovery.
| Authenticator | Current administrator recovery options | User action |
|---|---|---|
| Password | Assign or reset a password, generate a password automatically, email the password to the user, force password update, or enable password reset. | Use the new password, complete a required password change, or use password reset from the sign-in page. |
| Active Directory password | Configure password reset for Active Directory users when requirements are met. | Complete password reset from the sign-in page. |
| OTP | Configure OTP delivery settings and update user contact attributes such as email, mobile, phone, or configured custom OTP attributes. | Receive and enter the OTP through the configured delivery method. |
| Entrust Soft Token | Assign a token, send or resend activation instructions with Re-Activate, complete manual activation, synchronize the token, enable or disable the token, delete the token, or complete soft token PIN unlock. | Activate the token from the email, User Portal, or mobile app; provide manual activation, synchronization, or PIN reset values when required. |
| Google Authenticator | Assign Google Authenticator and send or resend an activation email with a QR code. | Activate Google Authenticator from the email QR code or from the User Portal when no email address is available. |
| Hardware token | Assign, enable, disable, view, delete, or manage hardware tokens according to hardware token settings. | Use the assigned hardware token during authentication. |
| Grid card | Create a new grid card, assign an existing grid card, email or export the grid card, enable or disable it, unassign it, or delete it. | Use the grid card during authentication so it changes from Pending to Active. |
| Knowledge-Based Authenticator | Manage KBA settings, questions, word maps, retained challenges, and user question-and-answer pairs. | Register or answer KBA questions when prompted. |
| Temporary Access Code | Assign a Temporary Access Code and share the code with the user. | Use the code within its configured lifetime and usage limits. |
| Smart Credential | Add a smart credential, send or resend activation email with a QR code, and manage the credential state. | Activate the smart credential from the email or from the User Portal when no email address is available. |
| Passkey/FIDO2 | View, enable, disable, rename, or delete registered Passkey/FIDO2 tokens. Administrators do not add Passkey/FIDO2 authenticators directly to a user. | Register a new Passkey/FIDO2 token from the User Portal. If the user lost a token, the administrator can delete the old token and help the user regain access through another recovery path. |
| Face Biometric | Configure Face Biometric and Entrust Identity Verification. Successful Entrust Identity Verification can create a Face Authenticator during onboarding or verification. | Complete Entrust Identity Verification or Face Biometric registration when prompted. |
| User certificate | Configure user certificate matching rules and trusted certificate requirements. Administrators can update user profile attributes used by matching rules. | Present a valid certificate that matches policy and user profile requirements. |
| Pass-through authenticator | Configure pass-through authenticator definitions and policies that call an external authentication service. | Complete the recovery or authentication process defined by the external service. |
| Magic Link | Send registration or password reset Magic Links when configured. | Open the Magic Link from email and complete the registration or password reset flow. |
For detailed procedures, see these authenticator-specific topics:
- Assign password authenticator
- View, edit, delete password authenticators
- Manage One Time Password (OTP) settings
- Assign and activate Entrust Soft Token authenticators
- Synchronize a soft token authenticator
- Activate a Google authenticator
- Unlock an Entrust Soft Token app
- Assign hardware tokens
- Manage hardware tokens
- Create or assign grid cards
- Manage assigned grid cards
- Manage Knowledge-Based Authenticators
- Assign a Temporary Access Code
- Add a smart credential
- View and manage Passkey/FIDO2 tokens
- Manage Face Biometrics with Entrust Identity Verification
- Manage user certificate authenticators
- Manage pass-through authenticators
- Magic Links solution guide
Understand unlock behavior
IDaaS lockout protects accounts and authenticators after repeated failed authentication attempts. The General settings control the lockout count, lockout mode, and lockout lifetime. See also Authenticator lockout behavior.
| Lockout or unlock type | Current behavior |
|---|---|
| Authenticator lockout mode | IDaaS locks only the authenticator that reached the failed-attempt limit. |
| User lockout mode | IDaaS locks the user after failed authentication according to the configured policy. |
| Administrator user unlock | The administrator unlock action unlocks the locked authenticators shown in the Unlock User dialog. |
| Password reset unlock | Password reset can unlock the user's account for password-related lockout when Unlock User Account is enabled. For Active Directory-managed passwords, IDaaS also sends the unlock request to Active Directory during the reset. |
| Entrust Soft Token app PIN unlock | PIN unlock clears a soft token PIN lock in the Entrust Soft Token app. It does not unlock the user account. |
| Inactivity lock | Administrators can grant a one-time sign-in during the configured inactivity grace period. |
User Portal self-service does not provide general self-unlock for locked authenticators. Users can perform actions that are enabled by User Portal authenticator policies, and password reset can unlock only password-related lockout when configured.
Keep user self-management aligned with recovery
User Portal policies control which authenticators users can view, add, edit, or remove. These settings are useful for recovery readiness because users can maintain contact methods and authenticators before they need recovery.
When you configure User Portal policies:
- Allow users to view authenticators when they need to understand which recovery options are registered.
- Allow users to add or edit authenticators only when the operation matches your security policy.
- Keep resource rules aligned with User Portal preferences. User preference order does not override resource rules.
- Avoid removing the only authenticator that users need for password reset or account recovery.
Recovery design checklist
Use this checklist to review the current configuration.
- Users have at least one registered second-factor authenticator before they need recovery.
- Automatically provisioned authenticators are configured for authenticators that every new user must receive.
- Administrators verify the user before performing assisted recovery or authenticator management actions.
- Administrators know when to require registration or verification again for an individual user.
- Bulk registration and verification procedures are available for larger recovery or rollout events.
- Group policies and resource rules align recovery options with user population and application risk.
- Users who must use Face Biometric for recovery have completed Entrust Identity Verification or have an active Face Authenticator.
- Administrators know which authenticators can be recovered directly and which authenticators require user self-registration from the User Portal.
- Password reset is enabled only for the groups and applications that need it.
- Password reset allowed second factors are ordered from stronger to weaker methods.
- Additional second-factor is enabled when one second factor is not enough for your risk model.
- Help desk administrators know which verify user authenticators are supported today.
- Administrators understand that Entrust Soft Token app PIN unlock is different from account unlock.
- Lockout count, lockout mode, and lockout lifetime match your security and help desk processes.
- User Portal authenticator permissions do not let users remove all recovery-capable authenticators.
- Temporary Access Code lifetime and maximum uses are limited for short-term recovery.
- User notifications are enabled when users must be notified about authenticator or contact changes.