Give every API its own private, service-scoped client-certificate chain. Invite a partner, watch them enroll a key that never leaves their machine, and see the first allowed call (and the expected denial) in minutes.
Why now
Sectigo’s published FAQ gives 10 February 2027 as the final cutoff for the clientAuth EKU in newly issued publicly trusted Sectigo SSL/TLS certificates. If your partners authenticate to your API with public certificates, their next renewal is the moment that matters. The exact effect depends on your inventory and renewal timing.
Your publicly trusted server certificate. Browsers and partners keep validating your API exactly as they do today.
How callers prove who they are: a separate, private chain per service, issued, renewed and withdrawn for you.
The problem
The hard part is everything around it: who may call which route, who renews, and whether “revoked” actually took effect.
Three commands
The CLI starts a sample Orders API behind the Mutual Trust enforcer, enrolls a workload with a key generated on your machine, and makes two calls with the same client: one the grant allows, one it doesn’t.
/orders succeeds. /admin/export is refused with a reason.curl -fsSL https://mutualtrust.io/install.sh | sh
mt gatewayMutual Trust quickstart · control plane https://api.mutualtrust.io sample Orders API on http://127.0.0.1:9001 Pairing code: XXXX-XXXX # approve in the portal Gateway ready.
mt enroll --token mtenr_…Enrolling workload 1. attestation accepted: challenge issued 2. generated P-256 key locally (private key never leaves this machine) 3. certificate issued · 24 h · renews automatically
mt call https://localhost:8443/orders
mt call https://localhost:8443/admin/export200 ALLOWED GET …/orders request req_… · policy revision 42 403 DENIED GET …/admin/export route_not_permitted not permitted to call this route or method
How it works
A solo developer can play both sides in two clearly labeled sample organizations.
Choose Sandbox and “Try the Orders API”. No card. You get an API owner, a sample partner and a sandbox trust fingerprint.
Run the enforcer beside your API, or use the gateway you already operate. It pins its verification key and reports the policy revision it applied.
Grant routes to a named partner workload. The partner accepts, generates a key locally and submits a signed CSR.
The allowed route succeeds and the restricted one is denied. Both receipts name the gateway, grant, time and revision.
Withdraw the grant and repeat the call. A new revision and a new denial close the loop; offline gateways show as pending.
What you get
Each trust space has its own trust anchor and issuing CA. Sandbox and production never share issuers or credentials.
The CLI generates the key on the partner’s machine and proves possession with a CSR. Mutual Trust never sees it.
Access is a grant to a named workload for specific routes and methods. A valid chain alone can’t authorize a call.
Short-lived leaves renew unattended with jitter and backoff. A failed renewal returns an actionable error with a correlation ID.
TLS success and authorization are recorded separately, so you can tell a bad certificate from a missing grant.
Deny state is written at once. Each gateway acknowledges the revision it applied, and stragglers are named, not hidden.
Every integration applies the same signed, deny-by-default policy and reports the revision it enforces. Run Mutual Trust inside the proxy you already operate, or put the standalone mTLS proxy in front of any API.
Browse gateway guidesWho it’s for
Give each partner exactly the routes they need, and remove access the day the contract changes.
Get a credential in your own environment, renew it unattended, and know why a call was refused.
Adopt one client-auth policy across internal and partner APIs, clouds and clusters, and show it.
Trust and evidence
The gateway checks the certificate, then checks policy per request, including resumed sessions. Unknown issuers, malformed identities, ambiguous routes and expired policy are refused.
{
"typ": "mt.receipt.v1",
"request_id": "req_…",
"gateway_id": "gw_…",
"revision": 42,
"tls": "verified",
"authz": {
"verdict": "deny",
"reason": "route_not_permitted",
"principal": "urn:mutualtrust:workload:…"
},
"method": "GET",
"route": "/admin/export",
"observed_at": "2026-11-14T09:30:12Z"
}Receipts are signed by the gateway (ES256) and sent to the control plane alongside its acknowledgments.
Pricing
A production connection is one production service paired with one consuming organization that has an active grant. Workloads, replicas and rotations within that pair are included. Partner invitations are free.
Free
No card
USD 299/month
10 connections · or USD 799/month for 50
Annual
Contract or site license
FAQ
Something missing? The docs go deeper on the API, enrollment and the security model.
No. Your API keeps its publicly trusted server certificate. Mutual Trust only changes how callers authenticate: with a separate, private, service-scoped client chain.
Sectigo’s published FAQ gives that date as the final cutoff for the clientAuth EKU in newly issued publicly trusted Sectigo SSL/TLS certificates. How it affects you depends on which certificates your partners use and when they renew.
No. The CLI generates the key on the partner’s machine and submits a certificate signing request with proof of possession. Only the public key reaches the service.
Gateways keep enforcing the last valid signed policy for up to five minutes, then fail closed for protected routes. Freshness and expected impact are shown in the portal.
The sandbox uses dedicated test roots, marked SANDBOX TEST, and time-limited credentials, so you can try the full flow without a card. Production trust spaces are provisioned with Sectigo PKI Operations on hardware-protected keys. Sandbox and production never share issuers or credentials. Request production access from the portal.
The API sponsor pays for production capacity. Invited partners take part in the sponsor’s relationship without buying a plan, and certificate rotations are included.
No. Mutual Trust is a standalone service with self-service signup. Existing Sectigo customers can adopt it without an SCM purchase.
The sandbox is free, needs no card, and runs the same flow your partners will use.