App developers can decide which authentication methods to register, when user authentication is necessary, and what is required to authenticate. Unfortunately, this approach means that the decision-making knowledge behind registration and authentication is hard coded in the app.
Your organization's security policies may dictate different levels of authentication depending on the user's context. Context can include factors such as the types of authenticators that the user has already registered, the user's location, the last time they logged in, and what they're trying to do, such as checking their account balance or paying for an expensive item. Authentication should consider these factors and respond appropriately. For example:
High-risk transactions might require two-factor authentication while medium-risk transactions might only need authentication with a single factor. Low-value transactions might not need any additional authentication beyond the user of an active session clicking a button to authorize.
A user who is in a different geographical location now versus yesterday should satisfy more stringent authentication requirements.
A user who registers a weak FIDO credential that uses a software-based keystore needs to also authenticate with SMS or email OTP.
A user whose location has moved 5000 miles in the last hour has had their credentials stolen, so deny authentication.
DigipassONE Adaptive Rulesets enable you to apply intelligent decision making to control the authentication methods that a user can register and, more importantly, customize how the user is verified based on contextual information. Adaptive Registration and Adaptive Authentication tailor their responses by evaluating data provided by your app, a small set of user history, and criteria from your organization, which is stored in the DigipassONE Server in rulesets.
Based on this information, the server renders a decision. For registration, a decision can be:
Deny: The user isn't given the option to register.
Suggest Registration: The user can register one or more authentication methods. They can defer registration or cancel out of it.
Enforce Registration: The user registers one or more required authentication methods. They cannot use the app for other tasks until they have registered those methods.
Ignore Registration: The user cannot register any authentication methods, but this is not an error.
For authentication, a decision can be:
Deny: The user's authentication request is denied
Allow: The user is immediately authenticated without any further action
Trigger authentication: The user must verify their identity using one or more authentication methods returned with this decision.
In addition to the decision, the Server can return sets of valid authentication methods called sequences. A sequence contains all the authentication methods that are recommended or required. Unless there are extenuating circumstances, a user is expected to register all the methods in a sequence so they can authenticate in the future or use all the methods in a sequence to securely authenticate.
Sometimes you won't know a FIDO authenticator's actual characteristics until after the user has registered it or used it to authenticate. This is especially the case with FIDO2 authenticators. You can still enforce your organization's criteria at this point in the process by using a PostOperation Check in an authentication rule or a Supplemental Check in a registration decision rule.
For authentication, a Post Operation Check compares the FIDO authenticator's characteristics to your organization's guidelines for authenticators. If the comparison is true, the Authentication Server performs an action instead of continuing to process the remaining methods in the sequence. The PostOperation Check represents the extenuating circumstance mentioned earlier.
For registration, the Supplemental Check detects if the FIDO authenticator is strong. If it is, registration is complete because no other authentication methods from the sequence are needed.
For authentication, the Post Operation Check's action is one of:
Allow: Authentication is complete because the authenticator is strong
Deny: Authentication fails because the authenticator is weak
Drop sequence: Authentication with the current authentication sequence fails because the authenticator is substandard. The Authentication Server switches authentication to use methods from an alternate sequence, if one is available from the succeeding Authentication Rule.
Components of Adaptive Authentication
Adaptive Ruleset: Encapsulates your organization's criteria and guidelines that govern registration and authentication. A ruleset contains an ordered set of Adaptive Rules.
Adaptive Rule: An Adaptive Rule can be either a Registration or Authentication Rule. A Registration Decision Rule examines a set of data and decides if a user can register and what authentication methods they can register. An Authentication Rule examines a set of data and concludes whether to deny, allow, or trigger authentication. Rules contain the components listed below. The figure below shows an example of an Authentication Rule with callouts for the components.
.png?sv=2026-02-06&spr=https&st=2026-09-30T02%3A18%3A34Z&se=2026-09-30T02%3A39%3A34Z&sr=c&sp=r&sig=hrmi9Gbpyn1ag%2B7MyUtVNgzZA2q6XiScGirbSso17t0%3D)
Figure 1 Components of an Adaptive Authentication Rule
Condition: Compares context data, signals, and user history against specific values or lists of values. If a condition evaluates to true, the rule's action is triggered.
Action: The decision.
For Registration Decision Rules, one of: deny, suggest registration, enforce registration, or ignore registration.
For Authentication Rules, one of: allow, deny, or trigger authentication.
Sequence: When the action is suggest registration or enforce registration, the sequence is the set of authentication methods that the user should or must register so they can successfully authenticate in the future. When the action triggers authentication, the sequence defines a set of authentication methods that the user must satisfy in order to be authenticated.
An Adaptive Rule can contain multiple sequences, these represent alternative methods to register or authenticate a user's identity. You can think of sequences as being joined by OR. Registration is complete when the user has registered methods from one sequence. To successfully authenticate, the user must validate their identity with all the methods listed in one sequence.Authentication method: This term refers collectively to FIDO authentication, FIDO OOB (out-of-band authentication), Email OTP, SMS OTP, Selfie + Picture ID (referred to as Photo ID) and external authentication methods (e.g. passwords). You can list these methods in combinations in a sequence. You can think of methods within a sequence as being joined by AND.
Post operation check: Optionally added to the end of an authentication rule. For some authenticators, their specific characteristics are only known after they are used to authenticate. A Post Operation Check compares the FIDO authenticator's characteristics to desired values.
If the comparison is true, the Authentication Server performs an action instead of continuing to process the remaining methods in the sequence. The Auth Server can finish authentication because the authenticator is strong, deny authentication because the authenticator is weak, or authenticate with a different sequence because the current sequence is no longer viable.Supplemental check: Optionally added to the end of a registration decision rule. For some authenticators, their specific characteristics are only known after a user registers them. A Supplemental Check compares the FIDO authenticator's characteristics to desired values.
If the comparison is true, the Authentication Server performs an action instead of continuing to process the remaining methods in the sequence. The Auth Server can finish registration because the authenticator is strong, or suggest or require that the user register an additional authenticator.Claim: A claim is a name-value pair that is used to return custom data when a rule succeeds. For example, a claim might be enable3DSBlob-true, in which case the 3DSBlob is returned when the rule succeeds. In order for the claim to be returned, a Registration Decision Rule's action must be either suggest registration or enforce registration. An Authentication Rule's action must be either allow or trigger authentication.
FIDO Policy: A FIDO policy enforces your organization's choice of valid FIDO authenticators when a user registers or authenticates. You can create different FIDO policies to restrict the FIDO authenticators for specific situations. For example, you can create an Adaptive Rule that triggers when a user has a specific device model that is considered vulnerable. Your rule's sequence can then use a FIDO policy to restrict the authentication method to a reliable FIDO authenticator for that model.
Similar to the Post operation check for an authentication rule, you can add a Post operation check to the end of a FIDO policy. A Post operation rule includes Post operation checks, and you define what action takes place when a Post operation rule succeeds: Allow, Deny, or increment a risk score. The total risk score can then be used to deny the policy’s success.
See Data used by Adaptive rules and FIDO policies for details on all of the available conditions and risk signals.
How Adaptive Registration Works
This section provides an overview of how Adaptive Registration works using a specific decision and registration sequences as an example. Using the admin console, specify an Adaptive Ruleset for your app or use the default ruleset. The figure below shows how context and signal data are sent to the Server. The Server evaluates each rule in that ruleset in order until one succeeds. In this figure, the successful Adaptive Rule contains an action of suggest registration and 3 sequences. Prior to returning the sequences, the Server filters out authentication methods that the user previously registered as well as methods not supported on the user's device.
.png?sv=2026-02-06&spr=https&st=2026-09-30T02%3A18%3A34Z&se=2026-09-30T02%3A39%3A34Z&sr=c&sp=r&sig=hrmi9Gbpyn1ag%2B7MyUtVNgzZA2q6XiScGirbSso17t0%3D)
Figure 2 Adaptive Registration Applies Rules Against Context, Signals, and User History
In this example, the DigipassONE App SDK receives the registration decision and 3 sequences from the DigipassONE Server. The App SDK presents the authentication methods from these sequences to the user and prompts them to register one. When the user selects the fingerprint authenticator to register, the App SDK interacts with the user to have them touch the sensor, as shown in the figure below.
(1).png?sv=2026-02-06&spr=https&st=2026-09-30T02%3A18%3A34Z&se=2026-09-30T02%3A39%3A34Z&sr=c&sp=r&sig=hrmi9Gbpyn1ag%2B7MyUtVNgzZA2q6XiScGirbSso17t0%3D)
Figure 3 The App SDK Interacts with the User to Register a Method
The user successfully registers the fingerprint authenticator. The App SDK sends the registration response and public key to the Server for validation against the FIDO policy. In this example, FIDO authentication with Fingerprint has a Supplemental Check defined for it. The Supplemental Check's condition tests the authenticator's characteristics to validate that it is a strong authenticator, its action is to finish registration. Unfortunately, this fingerprint authenticator is weak, so the user must register SMS OTP to complete the sequence.
(1).png?sv=2026-02-06&spr=https&st=2026-09-30T02%3A18%3A34Z&se=2026-09-30T02%3A39%3A34Z&sr=c&sp=r&sig=hrmi9Gbpyn1ag%2B7MyUtVNgzZA2q6XiScGirbSso17t0%3D)
Figure 4 The Newly-registered Authenticator Fails the Supplemental Check
The Server sends the SMS OTP method to the App SDK so the user can register it. The App SDK interacts with the user to complete registration. It prompts the user to provide a phone number and sends a passcode to the user's phone. SMS OTP registration is complete when the user enters the passcode they received in response to another prompt from the App SDK.
The user has registered both methods in a sequence so registration is now complete.
(1).png?sv=2026-02-06&spr=https&st=2026-09-30T02%3A18%3A34Z&se=2026-09-30T02%3A39%3A34Z&sr=c&sp=r&sig=hrmi9Gbpyn1ag%2B7MyUtVNgzZA2q6XiScGirbSso17t0%3D)
Figure 5 Registration Succeeds Because a Registration Sequence is Complete
How Adaptive Authentication Works
This section provides an overview of how Adaptive Authentication works using a specific decision and authentication sequences as an example. Using the admin console, specify an Adaptive Ruleset for your app or use the default ruleset. The figure below shows how context and signal data are sent to the Server. The Server evaluates each rule in the ruleset in order until one succeeds. In this figure, the successful Adaptive Rule contains an action of trigger authentication and 3 authentication sequences. Prior to returning the sequences, the Server filters out any methods that are not applicable to the user.
(2).png?sv=2026-02-06&spr=https&st=2026-09-30T02%3A18%3A34Z&se=2026-09-30T02%3A39%3A34Z&sr=c&sp=r&sig=hrmi9Gbpyn1ag%2B7MyUtVNgzZA2q6XiScGirbSso17t0%3D)
Figure 6 Adaptive Authentication Applies Rules Against Context, Signals, and User History
In this example, the DigipassONE App SDK receives the authentication decision and 3 authentication sequences from the DigipassONE Server. The App SDK presents the authentication methods from these sequences to the user and prompts them to pick one. When the user selects the fingerprint authenticator, the App SDK interacts with the user to have them touch the sensor, as shown in the figure below.
(1).png?sv=2026-02-06&spr=https&st=2026-09-30T02%3A18%3A34Z&se=2026-09-30T02%3A39%3A34Z&sr=c&sp=r&sig=hrmi9Gbpyn1ag%2B7MyUtVNgzZA2q6XiScGirbSso17t0%3D)
Figure 7 The App SDK Interacts with the User to Authenticate with a Method
The user successfully authenticates with the fingerprint authenticator. The App SDK signs the challenge and sends it back to the Server for verification against the FIDO policy. In this example, FIDO authentication with Fingerprint has a PostOperation Check defined for it. The PostOperation Check's condition tests the authenticator's characteristics to validate that it is a strong authenticator, its action is to allow authentication. This bypasses the remaining SMS OTP method in the sequence because verifying with a strong fingerprint authenticator satisfies the requirements for strong authentication.
The Server sends back a response to the App SDK that the user is successfully authenticated. In turn, the App SDK returns this to your app.
(1).png?sv=2026-02-06&spr=https&st=2026-09-30T02%3A18%3A34Z&se=2026-09-30T02%3A39%3A34Z&sr=c&sp=r&sig=hrmi9Gbpyn1ag%2B7MyUtVNgzZA2q6XiScGirbSso17t0%3D)
Figure 8 The Server Verifies Whether Authentication Succeeds
Summary
These examples underscore the amount of work entailed behind the scenes to implement and execute registration and authentication. They also emphasize the benefits of using the DigipassONE App SDK. Your app only needs to make one API call and wait for the final result. The App SDK and Server do all the work to enforce your standards and interact with the user.
Adaptive Rulesets offer you these advantages:
Context-based registration and authentication that uses data from the mobile device, user history, and context data about what your user wants to do to determine the best course of action.
Registration and authentication criteria is stored in rules contained in a ruleset on the Server instead of hardcoded in your mobile or web app. As a result, any updates to Adaptive Rules are immediately available to users, rather than dependent on the user downloading and installing an updated app.
Adaptive Rules are flexible because they offer the user several registration and authentication options and require a combination of authentication methods if needed.
A Supplemental Check or a PostOperation Check is applied after a user has registered or authenticated with a FIDO authenticator. It validates that the authenticator satisfies your organization's criteria. If the criteria is met, the Authentication Server bypasses the remaining methods in the sequence.
The App SDK and the Server are powerful enough to handle all necessary user interaction during registration and authentication, greatly simplifying what your client app has to do.