UbID Access
UbID Access is the product domain for adaptive authentication and secure access. It helps institutions determine how a person or authorized actor may enter a service, establish a session, and perform actions that require stronger assurance.
The product combines user experience with server-side policy. The interface may show available methods, but the authoritative decision about what is allowed belongs to controlled policy and validation services.
Authentication is not identity proofing
UbID distinguishes several questions that are often incorrectly combined:
- Identity proofing: what evidence establishes the person's identity?
- Authentication: does the current actor control an approved authenticator?
- Authorization: is that actor permitted to perform this action?
- Credential verification: is the presented credential valid and sufficient for this transaction?
UbID Access primarily addresses authentication and session entry. It can consume evidence from the other layers, but it does not replace them.
Core capabilities
Depending on deployment policy, UbID Access can support:
- phishing-resistant passkeys and device-bound authenticators;
- controlled biometric sign-in or step-up where appropriate;
- approved multi-factor methods;
- enterprise federation through established identity protocols;
- device registration and lifecycle management;
- server-side evaluation of allowed authentication methods;
- risk-based step-up for sensitive actions;
- bounded recovery or fallback that is narrower than ordinary sign-in;
- session evidence suitable for audit and incident review.
Adaptive policy
Adaptive authentication means the required method can change according to context rather than relying on one permanent login mechanism.
Relevant context may include:
- enrolled authenticators;
- device trust and lifecycle state;
- requested action;
- session age;
- prior assurance;
- account recovery state;
- institutional policy;
- jurisdiction or sector requirements.
Adaptive policy must remain explainable. A user should not be silently routed through weaker controls simply because a stronger method is unavailable.
Controlled fallback
Fallback exists to preserve continuity, but it can become the easiest path for an attacker if it is less governed than normal authentication.
A secure fallback should therefore be:
- short-lived;
- bound to the intended user and purpose;
- activated only after approved evidence;
- consumed or invalidated after successful transition;
- logged with enough context for review;
- unable to bypass higher-risk authorization requirements.
UbID Access treats fallback as a controlled exception, not as a permanent second login path.
Device lifecycle
Authentication assurance depends on the lifecycle of authenticators and devices. A secure deployment includes:
- enrollment under verified user intent;
- clear display of registered devices;
- approval for sensitive changes;
- revocation of lost or compromised devices;
- re-evaluation after recovery;
- rotation or renewal where required.
Device possession alone is not always sufficient for high-impact operations. Policy may require additional evidence or a trusted credential.
Relationship with other products
- UbID Proof provides evidence for enrollment and high-assurance step-up.
- UbID Wallet manages holder credentials and authorized presentations.
- UbID Recover restores continuity when authenticators or devices are lost.
- UbID Connect supports federation and identity-domain interoperability.
- UbID Pulse records authentication posture, service health, and security events.
What this product does not decide
Successful authentication proves control of an approved method within a defined context. It does not automatically prove every identity claim, authorize every business action, or make a credential trustworthy.
The relying institution remains responsible for access policy, role assignment, transaction authorization, and user support procedures.
Public documentation boundary
Public documentation covers authentication principles, lifecycle, federation, step-up, and fallback governance. Private thresholds, anti-abuse rules, session internals, customer policies, production configuration, and recovery bypass procedures remain restricted.
See also Authentication and Device Security, Digital Identity in UbID, and UbID Recover.