Skip to main content

Authentication and Device Security

Review status: This foundation page requires specialist review before public approval. Its claims must remain within the scope stated here.

Authentication establishes that a person or service controls an approved authenticator for a session or operation. It does not, by itself, prove every identity claim or authorize every action.

UbID supports strong, device-aware authentication with policy determined by controlled services. The available method can depend on enrolled authenticators, device state, transaction risk, institutional policy, and the assurance required for the action.

Passkeys and cryptographic authentication​

Passkeys use public-key cryptography so that the verifier stores a public credential rather than a reusable password secret. They can provide strong resistance to common phishing and credential-reuse attacks when implemented and governed correctly.

A passkey is still part of a lifecycle. Institutions must manage:

  • enrollment and binding to the legitimate account or identity;
  • approved authenticators and device platforms;
  • user verification requirements;
  • backup and synchronization policy;
  • device loss, revocation, and replacement;
  • recovery when no approved authenticator remains;
  • evidence of enrollment and use.

Device lifecycle​

A controlled device model distinguishes states such as pending, approved, active, suspended, revoked, or replaced.

Registering a new device should require evidence appropriate to the account and risk. Losing one device should not necessarily invalidate the person's entire identity, but the compromised device must be removable from the trusted set.

Device trust is contextual. An approved device may still require step-up authentication for a sensitive recovery, credential export, key operation, or institutional transaction.

Adaptive and step-up access​

Adaptive authentication evaluates the context of the requested operation. Relevant factors can include:

  • authenticator type and assurance;
  • device registration state;
  • recent successful verification;
  • transaction purpose and sensitivity;
  • credential or account state;
  • unusual session or risk signals;
  • institutional and jurisdiction policy.

The client may present available choices, but it does not decide the authoritative access policy.

Federation and credential trust​

Enterprise federation can provide centralized workforce or customer authentication and authorization. It does not replace credential trust services.

An authenticated enterprise session answers who controls the session according to the federation policy. A verifiable credential answers which issuer signed a claim and whether the claim satisfies verification policy. Both may be required in the same transaction.

Constrained fallback​

Fallback improves continuity only when it is more constrained than ordinary access. A safe fallback should be:

  • short-lived;
  • bound to the specific user and purpose;
  • issued only after approved evidence is evaluated;
  • limited in scope;
  • consumed or invalidated after successful transition;
  • visible in security evidence;
  • unavailable as a silent bypass for stronger authenticators.

The exact fallback methods and conditions are deployment-specific and remain outside public documentation.

Session protection​

A strong authenticator can be undermined by weak session handling. Institutions should protect:

  • challenge freshness and replay resistance;
  • audience and origin binding;
  • session creation and expiration;
  • token scope and revocation;
  • device and transaction context;
  • secure logout and account changes;
  • monitoring of unusual transitions.

Authentication evidence should be sufficient to explain the result without exposing reusable secrets.

Biometrics in authentication​

A local biometric can unlock a device authenticator without sending the biometric to the remote service. Remote biometric verification is a separate processing activity with different privacy, security, and governance obligations.

The documentation and user experience should distinguish these cases clearly.

Shared responsibility​

People must protect their devices and respond to compromise. Institutions must configure appropriate authenticators, lifecycle controls, fallback, monitoring, and support. Platform operators must enforce server-side policy and produce accountable evidence.

Public documentation boundary​

Authentication thresholds, fallback sequences, token lifetimes, customer policies, device fingerprints, fraud signals, private federation configuration, and bypass controls are not published.

See Security Model, Identity Proofing and Biometrics, and UbID Access.