End-to-End Client Continuity from the First Request

Does this sound like you?

If You Recognize Any of These,
Plumbus Was Built for Your Stack.

• Your platform requires authenticated users — but you cannot prove a given request actually came from one. A valid cookie or token is the only thing your services check, and they trust whoever presents it.
• Auditors, regulators, or your own threat model are asking how sessions resist replay and token theft. "MFA at login" is no longer a sufficient answer; the question is what happens to the credential after.
• Re-architecting your IdP, federation, or token formats is off the table. The blast radius is too large, the timelines too long, and the dependency on identity vendors too deep.
• You want one explicit, auditable enforcement point your security team owns directly — not credential-binding logic spread across every service, framework, and engineering team.

What Plumbus is

The Enforcement Layer Between Your Edge and Your Services.

Plumbus is a sender-constraint enforcement layer. It sits in the request path and verifies, on every protected call, that the request originates from the same client context that authenticated. It treats your existing authentication materials — cookies, JWTs, opaque tokens, proprietary session formats — as opaque. It does not issue them, does not parse their contents, and does not require your identity provider to know it exists.

The result is a single, deterministic control point that turns portable bearer credentials into non-portable, context-bound ones — without changing what your applications, users, or identity stack do today.

• Stops credential replay. Exfiltrated cookies and tokens cannot be reused from a different origin. Deterministic, not heuristic.
• One control point. Enforcement lives in one place, with one configuration and one audit trail — not in every service.
• No identity-stack rewrite. Your IdP, federation, MFA, passkeys, and token formats remain exactly as they are.
• Aligned with published standards. Delivers the same guarantee as RFC 9449 (DPoP) and RFC 8705 (mTLS-bound tokens), without requiring either at issuance time.
• Owned by the right team. Security owns the policy, the keys, and the enforcement. Application code, business logic, and developer workflows are untouched — engineering teams do not need to know this layer exists.

Deploy where you already operate

One Control. Whatever Form Factor Fits Your Architecture.

Plumbus is the same enforcement logic packaged for the place in your stack where you already terminate or inspect traffic. Pick the form factor that matches your operating model — change it later without rewriting policy.

All form factors share the same policy model, the same key material, and the same audit output — so you can start in one place and migrate without re-deriving your security posture.

Standards alignment

The Guarantee Your Auditors Already Recognize.

Sender-constrained authentication is not a novel concept. It is a recognized class of control with dedicated standards. Plumbus delivers the guarantee described in these standards at the service boundary, without requiring the infrastructure they normally depend on.

• RFC 9449 – OAuth 2.0 Demonstrating Proof-of-Possession (DPoP)
• RFC 8705 – OAuth 2.0 Mutual TLS & Certificate-Bound Access Tokens
• NIST SP 800-63B – Digital Identity Guidelines
• OWASP API Security Top 10 – Broken Authentication

Read the full standards argument and threat-model walkthrough →

Scope

Plumbus Adds One Property.
Everything Else Stays Yours.

• Not an identity provider, authorization server, or session store
• Not a replacement for MFA, passkeys, SSO, or your existing authorization logic
• Does not issue, inspect, or modify your authentication materials
• Does not introduce fingerprinting, device tracking, or behavioral profiling
• Does not require changes to your identity provider, applications, or clients