Context-Aware and Phishing-Resistant Authentication

VeridiumID 3.9 introduces Context Awareness, enabling authentication journeys to present users with contextual information about a sign-in request before authentication is completed.

The user must explicitly confirm or reject the request before proceeding with the configured mobile PIN or biometric authentication method.

Context Awareness can also bind the user's confirmation to the current VeridiumID authentication session using a server-generated cryptographic challenge. This provides additional protection against phishing, relay, replay, and unintended authentication approvals.

When used as part of a phishing-resistant authentication policy, VeridiumID can combine:

• Veridium QR authentication with contextual confirmation on the trusted mobile device; or

• FIDO authentication, using a security key or passkey.

Configure Context Awareness

Context Awareness is enabled from the Veridium Orchestrator by adding the Context Awareness command to the authentication journey where contextual confirmation is required.

The corresponding common command is:

commons.cmd_authentication_context_awareness

The underlying command uses the following configuration:

{
  "type": "AUTHENTICATION_AWARENESS",
  "executor": "VERIDIUM_SERVER",
  "contextConfiguration": {
    "title": "veridiumid.orchestrator.risk.context.dialog.title",
    "message": "veridiumid.orchestrator.risk.context.dialog.message",
    "actionPositive": "veridiumid.orchestrator.risk.context.dialog.action.positive",
    "actionNegative": "veridiumid.orchestrator.risk.context.dialog.action.negative",
    "requestSignature": false
  }
}

Configuration fields

The Context Awareness command is processed by the VeridiumID Server and applied to the authentication methods included in that journey step.

Configure challenge signing

The requestSignature option controls whether cryptographic binding of the authentication response to the Context Awareness challenge is mandatory.

Compatibility mode

"requestSignature": false

When set to false, challenge signing is supported but is not mandatory.

This mode provides backward compatibility during deployment when environments may contain mobile clients that do not yet support Context Awareness challenge signing.

Enforced challenge signing

"requestSignature": true

When set to true, the mobile client must sign the session-specific Context Awareness challenge as part of the authentication response.

Authentication responses that are not correctly bound to the challenge are rejected.

Recommended rollout

For environments being upgraded to VeridiumID 3.9:

1. Initially configure:

"requestSignature": false

2. Upgrade the deployed mobile applications to versions supporting Context Awareness challenge signing.

3. After compatible mobile clients have been deployed throughout the environment, change the configuration to:

"requestSignature": true

This enables strict session binding after the compatibility period is complete.

Add Context Awareness to an authentication journey

The Context Awareness command should be included in the challenge where the user must verify the authentication request.

For example, a Context Awareness challenge can contain:

commons.cmd_pin_mobile
commons.cmd_native_biometrics_mobile
commons.cmd_pin_browser
commons.cmd_authentication_context_awareness

The exact combination of authentication methods depends on the required journey and security policy.

For a phishing-resistant journey, only authentication methods appropriate for that security model should be included.

Handle rejected requests

VeridiumID 3.9 introduces Context Awareness conditions that can be used in journey transitions:

commons.is_context_awareness_rejected

Returns true when the user rejects the Context Awareness prompt.

commons.is_context_awareness_not_rejected

Returns true when the authentication request has not been rejected by the user.

A typical transition to a failed state can therefore use:

commons.is_context_awareness_rejected == true

while successful continuation can require:

commons.is_context_awareness_not_rejected == true
commons.is_authentication_successful == true

For example:

condition := policy if {
    input.journeyState == "Context_Awareness"
    transition_rejected
    policy = Failed
}

transition_rejected if {
    commons.is_context_awareness_rejected == true
}

condition := policy if {
    input.journeyState == "Context_Awareness"
    transition_accepted
    policy = Authenticated
}

transition_accepted if {
    commons.is_context_awareness_not_rejected == true
    commons.is_authentication_successful == true
}

These conditions allow the journey to explicitly separate user-confirmed authentication attempts from requests that the user identifies as unexpected.

Configure the Context Awareness dialog

The text displayed by the mobile application is controlled through VeridiumID internationalization.

The default Context Awareness configuration references the following keys:

veridiumid.orchestrator.risk.context.dialog.title

veridiumid.orchestrator.risk.context.dialog.message

veridiumid.orchestrator.risk.context.dialog.action.positive

veridiumid.orchestrator.risk.context.dialog.action.negative

Administrators can manage these entries from the VeridiumID internationalization configuration.

An English configuration example is:

{
  "key": "veridiumid.orchestrator.risk.context.dialog.title",
  "translations": {
    "en": "We detected an unusual sign-in attempt"
  },
  "tags": [ "PHONE" ]
},
{
  "key": "veridiumid.orchestrator.risk.context.dialog.message",
  "translations": {
    "en": "If this wasn't you, deny the request and secure your account."
  },
  "tags": [ "PHONE" ]
},
{
  "key": "veridiumid.orchestrator.risk.context.dialog.action.positive",
  "translations": {
    "en": "Yes"
  },
  "tags": [ "PHONE" ]
},
{
  "key": "veridiumid.orchestrator.risk.context.dialog.action.negative",
  "translations": {
    "en": "No"
  },
  "tags": [ "PHONE" ]
}

The entries can be managed from:

Veridium Manager → Settings → Internationalization

or through the corresponding i18n.json configuration in Advanced Settings.

After changing internationalization entries, test the authentication flow on a mobile device to verify that the expected text is displayed. An application restart may be required after internationalization changes.

User experience

When the mobile authentication reaches a Context Awareness step, the user is shown the configured title, message, and actions before completing the authentication method.

User confirms the request

Authentication continues with the configured PIN or biometric method.

If challenge signing is enabled, the resulting authentication response is bound to the current session challenge.

User rejects the request

Authentication stops and the session receives the:

REJECTED

status.

No subsequent authentication method in that Context Awareness step is completed.

Administrator visibility

Context Awareness decisions are recorded as part of the VeridiumID authentication session.

Administrators can review Context Awareness sessions in the session history and identify authentication requests explicitly rejected by users.

Sessions can also be filtered using the REJECTED session status, providing additional information for investigation of suspicious or unexpected authentication requests.

Phishing-resistant authentication policy

Context Awareness can be used as part of a broader phishing-resistant authentication strategy for applications protected by the VeridiumID Identity Provider.

Two supported security patterns are:

QR authentication with contextual confirmation

The browser or terminal creates a VeridiumID authentication opportunity and displays the QR code.

The trusted mobile device attaches to that authentication session and presents the Context Awareness information to the user.

The user confirms that the authentication request is expected and completes the required mobile authentication method.

When challenge signing is enforced, the response is cryptographically bound to that specific authentication session.

FIDO authentication

FIDO security keys and passkeys provide an alternative phishing-resistant authentication path using WebAuthn/FIDO origin-bound credentials.

Organizations requiring a phishing-resistant authentication policy should configure their journeys to permit the appropriate QR + Context Awareness and/or FIDO authentication paths while excluding authentication methods that do not provide the required phishing resistance.

Last updated: August 17, 2026