Technical Overview

The State of Play

At the root of the authentication problem is the fact that usernames are often easy to guess or discover, and people are generally very bad at using strong passwords. People also tend to re-use the same weak passwords across many different sites. Cybercriminals, armed with a victim’s username and password, will often attempt credential stuffing attacks, logging into many different sites using the same username/password combination.

To prove that users are valid, authentication systems generally rely on at least one of three authentication factors:

• Something you know (e.g. a username and password)

• Something you have (e.g. a second device, possession factor/MFA)

• Something you are (e.g. fingerprint or face recognition)

In the presence of increasingly sophisticated phishing methods, using only one authentication factor, such as a username/password, is highly problematic.

Many defenders have responded by implementing MFA, which includes an additional factor, such as an SMS message or push notification, as an extra step to confirm a user’s identity when logging in. By including an additional factor in the authentication process, compromised usernames and passwords become much less valuable to cybercriminals.

However, cybercriminals are creative, and they have devised clever ways to bypass authentication models that rely on commonly used bearer credentials.

Bearer Session Model

Today, the vast majority of web services rely on the Bearer model: whoever possesses the right secret value is accepted, regardless of how it was obtained or where it is used. This applies to both the login stage and the in-session requests.

Login stage

Passwords, SMS OTPs, and even authenticator app codes (TOTP or push) are bearer secrets. Whoever enters the correct value, or presses approve, is treated as the user. Attackers can phish these secrets in real time, relay them through a reverse proxy (Adversary-in-the-Middle, AiTM), or trick users into approving push requests (push fatigue).

Session stage

After login, servers issue session cookies or bearer tokens. Possession of this cookie/token alone is enough to act as the authenticated user until the token expires. If stolen through phishing, malware, or man-in-the-middle attacks, the attacker can bypass all login protections — including MFA — because the server cannot distinguish a legitimate origin of a bearer token.

Why is it dangerous

Bearer authentication secures only the initial login event. Once an attacker steals a bearer secret (whether a password, MFA code, or session token), they can fully bypass protections and impersonate the user. This makes bearer tokens and cookies one of the biggest targets in modern account-takeover attacks.

Continuous Cryptographic Trust

In the bearer authentication model, an adversary does not need the user’s credentials to sign in — the user effectively hands over an authenticated, ready-to-use bearer artifact.

Relock replaces these reusable artifacts with a per-request cryptographic proof of the origin-bound relationship between client and server. Instead of “whoever has the token can act as the user,” every request must carry a fresh Signed cryptographic One-Time Token (SOTT).

Bearer authentication trusts possession of a secret value; Relock trusts the origin-bound, continuous cryptographic synchronization between the client and the server. The SOTT token is derived from secret material that never leaves the client device or its origin. If the derived token payload matches the server-side secret, and the cryptographic signature is valid, the single request is granted.

Each time a SOTT token is verified, the server may trigger a key rotation. This ensures the secret material cannot be reused outside the legitimate origin or without the server’s knowledge. In simple terms: even if someone gains access to the secret, attempting to use it will immediately expose the attack. There cannot be any third-party actor between the client and the server (or multiple versions of the synchronization key).

This feature provides continuous visibility as well as observability. During a session, any attempt to reuse the secret material triggers a key collision and immediate session termination, making session hijacking an extremely difficult task for an adversary.

Cryptographic Design

Behind the scenes, Relock combines public-key cryptography (PKI) with symmetric key material. Trust is bound along four axes: device, server, origin, and time (rotation cadence). The core of this system is a symmetric key — Relock Tesseract — that powers the derivation of per-request tokens.

The Tesseract is not just random bytes of entropy. It is a symmetric key wrapped in a mechanism of interdependent encryption. Neither the client nor the server ever holds the raw value directly:

• Server-side: the secret is encrypted with a random key that exists only on the client-side.

• Client-side: the secret is encrypted with a random key that exists only on the server-side.

• Binding: the client-side encryption is bound to the browser’s fingerprint and an extra randomization key delivered from the server.

• In-memory only: both client and server access the raw secret material only in device memory; it is never stored in unencrypted form.

Both client and server also hold Ed25519 key pairs for the control plane. Each side signs messages with its private key and verifies them with the other side’s pinned public key. This provides mutual authentication and message integrity, independent of the Tesseract-derived SOTTs. On the client side, the Ed25519 signature key material is additionally randomized in storage, ensuring that it cannot be directly extracted or reused outside the legitimate browser environment.

This design ensures that neither side can reconstruct or use the Tesseract in isolation. Only when the legitimate browser and the Relock gateway are synchronized can the material be unlocked to derive a fresh Signed One-Time Token (SOTT). Immediately after use, the Tesseract rotates, ensuring that no reusable artifact exists for attackers.

Continuous Access Evaluation (CAEP)

Relock does not just align with CAEP principles — it can act as a CAEP transmitter. Whenever in-session events occur (e.g., secret material reuse, rotation, mismatch, or session termination), Relock can emit continuous evaluation signals to relying parties or upstream identity providers.

This means Relock provides both:

• Enforcement: Every request is cryptographically validated; invalid or replayed tokens are blocked in real time.

• Event transmission: In-session state changes are published as CAEP events, allowing downstream systems to immediately react (e.g., revoke access tokens, flag the account, trigger reauthentication).

By serving as a CAEP transmitter, Relock integrates naturally into Zero Trust ecosystems. It ensures not only that untrusted requests are blocked locally, but also that other connected services are informed of the compromise without delay.

Relock System Properties

• Device & origin binding: Proofs are valid only from the enrolled browser sandbox and origin that negotiated the Tesseract.

• Server interdependence: The gateway holds the authoritative version; any mismatch or reuse attempt fails verification.

• High-frequency rotation: Keys rotate at session start and on a policy-defined cadence (e.g., per request or at fixed intervals).

• Ephemeral tokens: SOTTs exist only in memory and are single-use, with replay prevention enforced by the gateway by default.

• Visibility signals: Any unauthorized reuse or version drift immediately triggers server-side detection, rejection, and event signal.

• In-memory only: Both client and server access the raw Tesseract material only in device memory; it is never stored in unencrypted form.

• CAEP transmitter: In-session events (reuse, mismatch, termination) can be emitted as Continuous Access Evaluation Protocol (CAEP) signals to inform upstream identity systems or relying parties.

Core Technical Characteristics

Characteristic	Relock Tesseract
Key location	Protected by OS keychain and ACL permissions, isolated by the browser sandbox; server-side encrypted and decrypted in memory only
Extractability	Non-extractable by default; strengthened by memory-only server-delivered random material and browser fingerprint binding
Material rekeying	Enforced at session start; configurable at per-request granularity or at fixed time intervals
Session hijacking	The gateway enforces single-use SOTTs; any reuse attempt is rejected
Compromise signals	Server-side detection of invalid or mismatched material; unauthorized attempts trigger immediate session termination
Server-side theft	Not applicable — server’s symmetric key is useless without the client contribution; both sides are required
Origin binding	Enforced by the browser sandbox and validated by Relock’s authentication gateway on each request
Phishing resistance	Continuous, request-level protection beyond login; out-of-origin requests are inherently detected
Human verification	Not inherent; can be combined with passkeys or other MFA during login

Client-Side Secret Storage

By default, browsers do not store authentication data as unencrypted files. They rely on the operating system’s ACL permissions and secure storage (e.g. Keychain on macOS, DPAPI on Windows, Keystore on Android), combined with origin-based process sandboxing. This means data access is restricted to the browser process itself.

In addition, the client-side sotrage is browser-fingerprint bound and incorporates in-memory-only, server-side stored randomization nonces. Even if storage is extracted, it does not guarantee successful use on another device or environment. Extraction of this secret material are far less effective, as an attacker would need to mimic the original device enviroment and still connect to the Relock authentication gateway for the material to be accepted (expose the use).

Security Assurance Under Fatal Compromise

It is natural to assume that hardware tokens or platform passkeys provide stronger assurance than a browser-bound mechanism such as Relock. In reality, the security model converges when we consider a device that has fallen into a fatal state of compromise (root- or kernel-level malware).

• Passkeys The private key is sealed in a secure enclave or TPM and cannot be exported. However, once the user provides a biometric or PIN gesture, malware with OS control can still invoke the enclave APIs to sign arbitrary challenges on the user’s behalf.

• Hardware tokens The key material never leaves the USB/NFC token. Yet after the user touches the key, malware can relay signing requests through the normal OS interfaces. The token cannot distinguish a legitimate browser call from a malicious one.

• Relock (Tesseract) The secret material is bound to the browser sandbox, OS keychain, and server interdependence. During use it must be decrypted in memory, so root-level malware could also access it. Like passkeys or hardware keys, Relock cannot guarantee secrecy on a fully owned device.

In a device compromise scenario, all three technologies can be abused in real time. Passkeys and hardware tokens excel at keeping their keys non-extractable, but malware can still use them once unlocked. Relock’s assurance is similar in that regard—but it differs in what happens next: Relock never produces a long-lived artifact. Each proof is one-time-use and replay-protected, so compromise is self-limiting and detectable, whereas sessions established with passkeys or hardware tokens can still be hijacked and replayed invisibly.

Method Comparison

Characteristic	Relock Tesseract	Passkey	Hardware Key
Key storage	Keychain + server nonce	Secure enclave	Hardware chip
Extractability	Hardened + ephemeral	Non-extractable	Non-extractable
Rekeying	High-frequency rotation	Static private key	Static private key
Origin binding	Request-level	Login-level only	Login-level only
Device binding	Sandbox + Fingerprint	Limited (platform bound)	Absolute
Session hijacking	Resilient	Vulnerable via stolen cookie	Vulnerable via stolen cookie
Compromise signals	Discoverable	None	None
Server-side risk	Not applicable	Cloud-based if synced	Not applicable
Phishing resistance	Continuous per-request	At login only	At login only
Human verification	Optional (MFA/passkey)	Built-in biometric	Built-in biometric

Regulatory Alignment

Relock is designed not only as a strong security control, but also as an enabler for organizations facing demanding compliance requirements. Because Relock replaces bearer tokens with continuous, per-request cryptographic proofs, it directly addresses common mandates for strong authentication, session integrity, and compromise detection.

PSD2 / Strong Customer Authentication (SCA) Requires multi-factor authentication and dynamic linking of authentication to the transaction context. Relock enforces per-request, origin- and device-bound Signed One-Time Tokens (SOTT). This satisfies the dynamic linking requirement, since each proof is unique, non-reusable, and cryptographically tied to the transaction.

NIS 2 Directive (EU) Focuses on resilience of essential/critical services, including incident detection and prevention of credential misuse. Relock provides real-time misuse detection: any replay, mismatch, or unauthorized use of secret material is blocked and logged. This supports NIS 2 requirements for monitoring, detection, and rapid response.

NIST Digital Identity Guidelines (SP 800-63B) Defines Authenticator Assurance Levels (AAL). Relock supports AAL2/AAL3 by providing device-bound, origin-bound, and replay-resistant authenticators. Continuous proof-of-possession strengthens assurance throughout the session, in line with NIST’s guidance on verifier compromise resistance.

SOC 2 (Trust Services Criteria) Requires strict access controls, monitoring, and detection of unauthorized use. Relock enforces continuous validation on every request, preventing unauthorized reuse. Unauthorized attempts are blocked and generate auditable events, supporting SOC 2 requirements for security and monitoring.

PCI DSS v4.0 (Payment Industry) Requires MFA for administrative and user access to cardholder data, along with secure session management. Relock ensures that no session artifact can be replayed. Each request is tied to a cryptographic proof, reducing account takeover and session hijacking risks.

HIPAA (US Healthcare) Requires safeguards to protect electronic protected health information (ePHI) against unauthorized access. Relock enforces continuous cryptographic validation of user sessions, preventing hijacking of healthcare portals and unauthorized exposure of sensitive data.

ISO/IEC 27001 / 27002 Global standards for information security management systems (ISMS). Relock provides strong technical controls for access security, session integrity, and incident detection, aligning with multiple Annex A controls (e.g. A.9, A.12).

CIS Controls v8 Best practices for enterprise defense. Relock directly supports Control 5 (Account Management) and Control 6 (Access Control Management) by enforcing per-request, device- and origin-bound authentication beyond login.

FFIEC Guidance (US Banking) Requires strong authentication for consumer online banking portals. Relock mitigates account takeover risks by preventing authentication bypass via session-token replay — a key threat in financial services.

CISA Zero Trust Maturity Model (US Federal) Emphasizes continuous authentication and device validation, not just one-time login. Relock enforces per-request validation, proving device trust on every request and enabling continuous verification within a Zero Trust framework.

GDPR (EU) Requires organizations to protect personal data with state-of-the-art security controls. Relock ensures sessions cannot be hijacked or replayed. Any attempt to misuse secret material is detected in real time, reducing the risk of personal data breaches.

FIPS 140-3 (US Federal) Defines cryptographic module validation for federal use. Relock leverages modern, standardized algorithms (e.g. Ed25519), suitable for deployment in environments with FIPS-aligned requirements.

Compliance Matrix

Relock has been designed to meet the requirements of a wide range of regulatory and industry frameworks. The matrix below maps key requirements to Relock’s enforcement capabilities.

Framework	Key Requirement	How Relock Addresses It
PSD2 / SCA (EU)	Requires MFA and dynamic linking of transactions.	Relock issues per-request SOTTs, origin- and device-bound, fulfilling the “dynamic linking” requirement.
NIS 2 (EU)	Resilience and detection of cyber incidents across critical infrastructure.	Relock detects secret misuse in real time, rejects replay, and logs unauthorized attempts.
NIST SP 800-63B (US)	Defines Authenticator Assurance Levels (AAL2/AAL3).	Relock provides device-bound, non-replayable proofs, supporting continuous assurance beyond login.
SOC 2 (Global)	Trust principles: security, availability, confidentiality.	Relock enforces continuous session validation and generates auditable events for unauthorized activity.
PCI DSS v4.0 (Payment)	Requires MFA and strong session management for cardholder data.	Relock ensures session control with cryptographic replay prevention and per-request validation.
HIPAA (US Healthcare)	Protects electronic health data (ePHI) against unauthorized access.	Relock prevents session hijacking and ensures cryptographic integrity of access to sensitive records.
ISO/IEC 27001	Global standard for ISMS.	Relock provides strong technical controls for access security and session integrity, aligned with ISO Annex A controls.
CIS Controls v8	Best practices for enterprise defense.	Relock supports Controls 5 & 6 (Account/Access Management) with per-request device-origin proofs.
FFIEC (US Banking)	Requires strong authentication for online banking portals.	Relock prevents account takeover by blocking cookie/session replay attacks.
CISA Zero Trust (US)	Requires continuous authentication and device validation.	Relock enforces per-request, device- and origin-bound proofs, aligning with Zero Trust requirements.
GDPR (EU)	Requires state-of-the-art protection of personal data.	Relock ensures sessions cannot be hijacked or replayed; misuse is detected in real time.
FIPS 140-3 (US Federal)	Cryptographic module validation standard for federal systems.	Relock uses modern, standards-based cryptography (Ed25519), suitable for FIPS-aligned environments.

Technical Summary

Relock closes the major gaps of the bearer model — cookie or token replay and adversary-in-the-middle (AiTM) attacks — while providing real-time signals of misuse. The remaining residual risk is concentrated in the areas that no crypto scheme can fully eliminate: same-origin code execution (XSS) and full endpoint compromise.

When paired with strict XSS hygiene, a strong origin/TLS posture, and careful server-side binding of SOTTs to intent, Relock delivers a level of assurance comparable to passkeys or hardware keys — with the added benefit of continuous protection not only within a single session, but across the entire server–client relationship lifetime.