The problem
Portability Is the Weakness
Every bearer credential your platform issues is a transferable claim. Whoever holds it gets access — your authenticated user, an attacker who lifted it from a browser, a process that exfiltrated it from memory. MFA verified the user at login. Passkeys made that login phishing-resistant. Neither does anything to the credential once it is in circulation.
This is not a novel risk. Cross-context credential replay is a recognized class of attack, documented by every major security body and addressed by published standards for sender-constrained authentication:
- OWASP Session Management Cheat Sheet
- OWASP API Security Top 10 – Broken Authentication
- NIST SP 800-63B – Digital Identity Guidelines
- RFC 9449 – OAuth 2.0 Demonstrating Proof-of-Possession (DPoP)
- RFC 8705 – OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens
The standards exist. The reason most deployed systems still rely on portable bearer credentials is that adopting these approaches the traditional way requires re-engineering the identity provider, the token format, and every resource server that validates them. Few organizations are positioned to absorb a change of that blast radius.
The gap
Authentication Proves Identity.
It Does Not Constrain Origin.
Your existing controls protect the authentication event. Nothing in your stack protects the credential after authentication completes. That is the gap Plumbus closes — and it is the gap auditors and regulators increasingly ask about.
| Control | What it enforces | Prevents credential replay? |
|---|---|---|
| MFA | Identity at login | No |
| Passkeys / FIDO2 | Phishing-resistant identity at login | No |
| WAF / Anomaly Detection | Probabilistic signal analysis | No — heuristic, not deterministic |
| Plumbus | Deterministic context continuity enforcement per request | Yes |
The change
Authentication Materials Become Non-Portable
Credentials function as bearer tickets. Whoever holds them can use them from any origin. Exfiltration equals access — and your only signal that something is wrong is a heuristic alert after the fact.
Credentials are bound to the client context that authenticated. Requests from outside that context are rejected at the service boundary, before application code runs, with a deterministic policy decision in the audit log.
- Exfiltrated credentials cannot be replayed from a different origin
- Proof of possession is verified on every protected request — not only at login
- Enforcement is deterministic: cryptographic verification, not behavioral heuristics
- Every rejection is an explicit policy event, not a probabilistic alert
- Works with existing tokens, cookies, and proprietary credentials as-is
Authentication proves identity.
Plumbus enforces context continuity.
Standards alignment
The Guarantee Is Already in the Standards.
Plumbus Delivers It Without the Infrastructure Bill.
When auditors, regulators, or your own security review ask how your platform constrains credential reuse, the named-and-respected answers are RFC 9449 (DPoP) — explicitly recommended by RFC 9700 — and RFC 8705 (Mutual TLS). Both define sender-constrained authentication. Both are published, peer-reviewed, and unambiguous. Both are also, in practice, almost never deployed end-to-end — because each demands infrastructure most organizations cannot economically commit to.
Standard DPoP requires your identity provider to embed a public-key thumbprint in issued tokens and every resource server to validate that claim on every request. It is also JWT-centric — systems using cookies or proprietary credentials must rework token issuance to participate. RFC 8705 demands a client-certificate posture across every browser, mobile client, and partner integration. Both are correct. Both are engineering programs measured in quarters, not sprints.
Plumbus enforces the same cryptographic guarantee at the service boundary, treating your existing authentication materials as opaque. Your identity provider is never involved. Your tokens are not reissued. Your applications are not modified. The control is a layered addition to your stack, not a replacement for any part of it — and it satisfies the same audit question the standards exist to answer.
Where it matters
Any Endpoint Where "The Token Was Valid"
Is Not an Acceptable Incident Report
- Administrative consoles and privileged access
- Financial transactions — withdrawals, transfers, billing
- API key issuance and credential management
- Actions that are irreversible or externally visible
- Any surface where WAF heuristics are insufficient and deterministic enforcement is required
Plumbus does not replace application authorization. It enforces that requests originate from the client context that authenticated, before any application logic runs.
Scope
Plumbus Adds One Property.
Everything Else Is Unchanged.
- Not an identity provider or authorization server
- Not a replacement for MFA, passkeys, or SSO
- Does not issue, inspect, or modify authentication materials
- Does not introduce fingerprinting, device tracking, or behavioral profiling
- Does not alter application-level authentication or authorization logic
- Does not store session state or authentication materials server-side