EN | FR

What Is SAPS?

SAPS is a modern authentication architecture that fixes the root flaw of the internet’s identity model: third‑party services should never handle your primary credentials.

How Breaches Happen

The Core Principle

Identity needs two credentials, not one.

The internet currently runs on a single‑credential identity model. That model is the reason breaches escalate, identities collapse, and attackers reuse stolen passwords everywhere.

SAPS introduces a boundary the internet has never had:

Your primary password stays ONLY at the identity provider.

Third‑party services never see it, never store it, and never become a liability for it.

The Two‑Credential Architecture

1. Primary Password (Identity Credential)

2. Secondary Password (Service Credential)

This separation creates a boundary that prevents global compromise.

Token‑Based Access

Third‑party services never receive passwords. Instead, they receive:

Non‑escalating SAPS tokens

These tokens:

A breach becomes a contained incident — not a global disaster.

Escalation Prevention

The old model allows attackers to escalate from a weak service into your entire identity.

SAPS blocks escalation at the architectural level.

This is the boundary the internet has been missing for 20 years.

Why SAPS Works

SAPS fixes the root cause of identity compromise:

No shared credentials = no global compromise.

SAPS is not a product. It is a boundary — a rule — that the internet should have had from the beginning.

Scenario: The Fake Sign‑In Partner Trap

Here’s how an attack happens today, even when you use a trusted sign‑in partner like your bank.

1. You click “Sign in with my bank”

The site looks legitimate. The button looks real. Nothing seems suspicious.

2. You are redirected to a page that looks exactly like your bank’s login

Same logo. Same colors. Same layout. The URL has one tiny difference you don’t notice.

3. You enter your real bank password

At that exact moment, the attacker already has it. The redirect does not protect you — the exposure happened before it.

4. The fake page forwards you to the real bank login

You authenticate normally. You never realize your password was stolen.

5. The attacker logs into your real bank account using the password you just gave them

The sign‑in partner cannot protect you from typing your password into a fake page.

SAPS eliminates this attack completely.

With SAPS:

Result: even a perfect imitation site cannot steal anything. The attack dies before it begins.

Frequently Asked Questions

“If I use my bank as a sign‑in partner, isn’t that already safe?”

No. The redirect does not protect your password. If you type your real bank password into a fake page, the attacker has it before the redirect even happens. SAPS prevents this because your real password never leaves the identity provider.

“But my bank notifies me if someone logs in — isn’t that enough?”

No. Notifications happen after the attacker already has your password. At that point they can reset MFA, call the bank pretending to be you, or use recovery flows. SAPS prevents the password theft entirely, so there is nothing to notify about.

“How can an attacker get past MFA if they don’t have my PIN?”

MFA protects the login, not the password. Once an attacker has your real password, they can trigger MFA fatigue, socially engineer the bank, perform SIM‑swap, or use recovery flows. SAPS eliminates the root problem: the attacker never gets your real password.

“Does SAPS mean I have two passwords?”

No. SAPS uses secure device autofill. You never type or manage the secondary password. It fills automatically only on the real domain, and never on a fake site.

“What happens if a service using SAPS gets breached?”

Only the service‑specific token is exposed. It cannot be reused, cannot escalate, and cannot access your identity. The service must secure its own environment — SAPS ensures the breach cannot cross that boundary.

“Can a secondary password be used to recover my account?”

No. A secondary password is a service credential, not an identity credential. Allowing it to recover your identity would instantly break SAPS isolation and turn it into a primary. If you lose your primary, you reinstall SAPS and re‑verify your recovery accounts — identity is never recovered through a service credential.

“Why not just use hardware keys like YubiKey or FIDO tokens?”

Those systems are designed for enterprise IT teams, not everyday people. Most users will not carry hardware keys, manage backups, or understand device‑bound cryptography. SAPS provides the same level of isolation and protection without hardware, without complexity, and without changing user behavior.

“Is SAPS the same as passkeys?”

No. Passkeys protect devices, not identity. They still rely on centralized recovery flows and ecosystem lock‑in. SAPS protects your identity itself by isolating it from every service you use and preventing any credential from escalating.

“What if someone steals my secondary password?”

Nothing else is compromised. A secondary password is locked to one service, cannot be reused, cannot escalate, and cannot access your identity. SAPS contains the breach to that single service.

“Can I recover my SAPS account if I lose access?”

Yes — but only with your primary password. The primary is your identity credential, and it is the only thing that can restore your SAPS setup. The secondary password is a service credential and cannot be used for recovery. This separation is what prevents attackers from escalating a stolen service password into full identity access.

How Breaches Happen Back to Home