AffirmedID Auth

Executive Summary

AffirmedID Auth is a FIDO2 authenticator application that serves as the user-facing identity device for the AffirmedID platform. It is the point where phishing-resistant authentication begins and continuous identity assurance is maintained — from first enrollment through every subsequent session.

Auth does more than complete an authentication ceremony. Once enrolled, it becomes an active component in the ongoing session: streaming four real-time trust metrics to the AffirmedID cloud API, responding to push-delivered authentication challenges from relying parties, and maintaining the continuous assurance signals that feed the Pulse Policy Decision Point throughout the life of every session.

Enrollment is a structured, one-time process that binds the user, device, verified contact information, and a FIDO2 credential to a single account record — federated to all connected relying parties from the moment of registration. Subsequent authentication requires no separate per-RP enrollment: the same credential and account are recognized everywhere, with step-up and re-authentication handled transparently through the same app and the same push-challenge flow.

For organizations deploying Passkeys, Auth also solves a problem that Passkey alone cannot. Apple and Google do not permit Passkey to confirm who the user actually is — only that a registered device was present. Auth steps in alongside Passkey to assert verified user identity to the relying party, closing that gap and bringing the authentication event to full NIST AAL3 compliance. Passkey proves the device. Auth proves the person.

What Auth Is

Auth is a mobile application with three distinct but inseparable roles within the AffirmedID platform:

• FIDO2 Authenticator — Auth holds a device-bound FIDO2 credential registered with the AffirmedID cloud API. This credential is used to complete CTAP-based authentication ceremonies initiated by the API in response to login events at federated relying parties. Authentication is phishing-resistant by design: challenges are delivered by the platform, not by the RP, and assertion responses are cryptographically bound to the registered device.
• Continuous Authentication Device — Auth is the source of the four real-time trust metrics that power the Pulse continuous authentication and authorization engine. From the moment a session begins, Auth streams Identity Trust, Proximity Trust, 3D Location Trust, and Device Health scores to the cloud API. These signals do not stop at login; they persist throughout the session and feed every AuthZEN authorization decision made by the Pulse Policy Decision Point.
• Adjunct Identity Assertion — Auth, when used in conjunction with a user's Passkey on the same device, steps up the Passkey ceremony to full NIST AAL3 compliance by verifying user identity and asserting that with proofs to the relying party — enabling RP confirmation of user identity. A critical need in a time of cybersecurity uncertainty.

Enrollment

Auth enrollment establishes the account, binds the device, and registers the FIDO2 credential in a single structured flow. Enrollment is required before any authentication can occur.

Enrollment Steps

1. User installs Auth on their mobile device
2. User initiates registration within the app
3. App registers with the AffirmedID cloud API:
   • A user record is created in the API
   • Email address is verified
   • Phone number is verified
   • Device-bound FIDO2 credential is registered with the same API
   • User record — including the FIDO2 registration — may be federated to relying parties
   • User is assigned an API token for account management operations
4. PIN login is configured and enforced on the device

The result is a single account record, federating one user identity across all authorized RPs. No per-RP enrollment is required after the initial registration.

RP Federation Steps

Relying parties configure federated access to Auth users through their AffirmedID Nexus dashboard:

1. RP initiates the process on the Nexus dashboard, providing the user account name (verified email address)
2. An alias email account can be added and linked to the record
3. Other settings and policies are assigned as necessary
4. On submission of the federation request, user authentication and acceptance occurs
5. Once accepted, a logical link is set in place between user and RP
6. User is now provided access to authorized accounts

Trust Score Metrics — What the RP Sees

Trust scores are viewable on Nexus, embedded in logs, and delivered to Splunk when configured. The following are examples taken from a live session:

Authentication Flow

Authentication is initiated when a user attempts to log in to a federated relying party account using their verified email address or an alias linked to it. The RP delegates credential verification to the AffirmedID cloud API, and the following sequence occurs:

Continuous Authentication Metrics

From the moment a session is established, Auth continuously streams four trust metrics to the AffirmedID cloud API. These metrics feed the Pulse Policy Decision Point and underpin every AuthZEN authorization decision made during the session.

BLE Advertiser — Active Proximity for Sentinel

In addition to passive BLE proximity scanning, Auth operates as a BLE advertiser. This enables AffirmedID Sentinel — the physical access control component of the platform — to actively poll for the user's presence when proximity verification is required at a physical access point. The user's device becomes discoverable to Sentinel polling events without requiring any user action.

Account Transfer

Auth supports a structured account transfer process for users who replace their device. Transfer preserves the user's account and all RP federations — no re-enrollment at individual relying parties is required.

1. User installs Auth on the new device
2. During registration on the new device, the user provides the API token from the existing account
3. Email address and phone number are verified on the new device
4. Account — including all RP federations and the FIDO2 registration — is transferred to the new device
5. The old device's credential is invalidated

Key Benefits

1. Phishing-Resistant by Architecture

FIDO2 CTAP authentication cannot be intercepted, replayed, or redirected by a fraudulent site. Challenges originate from the AffirmedID API and are delivered directly to the registered device. The user never submits credentials to the RP. This satisfies NIST AAL2 and AAL3 requirements for phishing-resistant authentication in a single ceremony.

2. One Enrollment — All Relying Parties

A single Auth enrollment creates a federated identity that is immediately recognized by all connected RPs. Users do not re-enroll at each application. Administrators do not manage per-RP credential stores. The AffirmedID cloud API is the single source of identity truth, and federation ensures it propagates everywhere from the moment of registration.

3. Continuous Trust — Not Just a Login Event

Auth does not stop working after the login ceremony. Its four real-time trust metrics stream continuously to the Pulse PDP for the life of the session. Every authorization decision made by the PDP reflects the current state of the user's identity, proximity, location, and device — not a credential from login that may have been valid minutes or hours ago.

4. Push Challenges — No Polling Required

Authentication challenges are delivered to the device via FCM or APNs push notification. The user receives a prompt, opens the app, reviews the challenge, and responds — all within seconds of the login event at the RP. There is no user-initiated polling, no shared secret to enter, and no QR code to scan.

5. Seamless Device Replacement

Account transfer to a new device requires only the API token and verification of registered contact information. All RP federations transfer with the account. Users retain uninterrupted access to every connected application on their new device from the moment transfer completes.

Architecture Overview

Auth operates as the user-carried identity device within the broader AffirmedID platform architecture. Its interactions with the platform are continuous, not point-in-time:

Scenario Comparison

How Auth — as a FIDO2 authenticator and continuous authentication device — responds to attack and risk scenarios that conventional authenticators cannot address:

Conclusion

AffirmedID Auth is the identity device that makes the AffirmedID platform work for users. It provides phishing-resistant FIDO2 authentication at enrollment and at every subsequent login — and it provides continuous identity assurance throughout every session, streaming the real-time trust signals that the Pulse PDP needs to make authorization decisions that reflect reality, not a credential from hours ago.

For organizations that have deployed AffirmedID Connect and Pulse, Auth is the device that closes the loop: the piece that users carry, the piece that proves who they are, and the piece that keeps proving it — from first enrollment to the last action of the last session.