Authentication

When acting as the Primary Identity Provider, both OIDC and SAML perform the initial authentication ceremony required to establish their respective sessions. They also support reauthorization and reauthentication whenever session context, risk posture, or policy requires it.

For authentication, the Relying Party has a choice: conventional Passkey or Auth passkey. Both are based on FIDO2, but they differ in meaningful and deliberate ways.

The first distinction is assurance level. Passkey provides Single-Factor Authentication (SFA) with a single assertion: FIDO2. Auth, by contrast, provides Multi-Factor Authentication (MFA) through dual assertions: FIDO2 plus an explicit identity assertion. In many environments, the implicit identity assurance assumed by Passkey is sufficient. However, in regulated or high-assurance contexts where MFA is mandated, that distinction can be decisive. This is why the choice exists.

A second, and more critical, distinction concerns how FIDO2 private keys are stored. Passkeys may be device-bound or cloud-synced. Auth permits no such ambiguity: keys are always device-bound.

Cloud-synced Passkeys, favored for their usability benefits, improve the user experience but do so at a measurable security cost. Any Relying Party considering Passkey should therefore evaluate the tradeoff between reduced friction and increased risk.

AffirmedID deliberately takes no position in that debate. Instead, it provides a clear choice: accept the usability gains and associated risks of Passkey, or eliminate those risks by selecting Auth.

Pulse, Continuous Authentication

The decision to deploy Pulse and its continuous authentication capabilities ultimately rests with the Relying Party (RP). The primary motivation for using Pulse is to extend authentication security beyond the initial login event to encompass the entire session lifecycle, from authentication through logout. Doing so, however, introduces additional considerations regarding how the selected provider protocol (OIDC or SAML 2) integrates with both the client application(s) and the IAM platform.

Today, most RPs rely on IAM service providers for authorization, governance, and identity lifecycle management. While an IAM typically designates a preferred Primary Identity Provider, enabling Pulse requires that AffirmedID assume this role for both OIDC and SAML deployments. In practice, this is generally a straightforward IAM configuration change and does not present a significant barrier.

A more complex consideration is the adoption of modern standards that were only formally approved in September 2025. Although widespread IAM support is expected over time, such support cannot be assumed as of January 2026. Pulse can operate regardless of IAM support for these standards, but the RP must understand the resulting implications.

These protocols, identified in the diagrams below as Shared Signals Events (SSE) and Continuous Access Evaluation Profile (CAEP), together enable continuous monitoring solutions such as Pulse to exert finer-grained, near-real-time influence over active sessions in coordination with IAMs and cloud APIs.

At a high level, CAEP is responsible for delivering policy updates and access decisions to the provider service, while SSE enables the provider service to publish security-relevant events back to the IAM. CAEP is also used by cloud APIs and their Policy Decision Points (PDPs) to communicate decisions to the corresponding Policy Enforcement Points (PEPs).

When an IAM does not yet support SSE and CAEP, Pulse continues to perform its monitoring and risk evaluation functions. However, enforcement is constrained: a reauthentication or remediation action signaled by the PDP cannot be applied until the next protocol transition event, such as a SAML or OIDC reauthorization. The associated downside risk is that certain policy responses—for example, those triggered by detected proximity violations—may be delayed rather than applied immediately.