Solutions · By problem
Replace or augment PKI
Public key infrastructure (PKI) still leaves reusable request credentials in place even when certificates and mTLS are healthy. ENI6MA replaces the part that keeps breaching you - the credentials that authorize requests - while certificate hierarchies and mTLS can stay. Recommended stack: Cloud, with IdP/PKI coexistence as the default migration posture.
PKI coexistence
PKI remains for channel while ENI6MA owns request authorization
Migration in four steps
Inventory, shadow, proof-required, then retire migration steps
What you retire
- Bearer tokens and service certificates used as lasting request capabilities from anywhere until rotation
- OTP MFA or session cookies as lasting authorization factors on high-risk mutate routes
- Treating channel identity alone (mTLS peer, device cert) as proof that this body may run once
Recommended stack
- Public
- Cloud
- Sovereign
- Agent
- Institutional
- OEM
Cloud - Gate on high-risk routes; Foundry for circuit mint; Control for registry and nonce ledger. Keep your IdP for authentication and your certificate estate for transport identity. Scope: request authorization only - not a rip-and-replace of PKI or directory. See Security → Coexistence for the staged path that keeps IdP and certs intact while routes flip to proof-required.
One-minute capability description
Channel identity (mTLS, device certs, document signatures) remains useful. The failure buyers have lived through is reusable request credentials: bearer tokens and service certificates used as capabilities that work from anywhere until rotation catches up. ENI6MA layers request-level authorization on top. An envelope (a one-time cryptographic authorization for a single request) proves that this message may change the world once. Gate enforces that proof at the request boundary; Control holds the registry and durable nonce ledger; Foundry mints the per-identity circuits that produce the proofs. Coexistence is the default migration posture - inventory high-risk routes, shadow mode, then proof-required per endpoint. Absolute binding and expiry language is claim-scoped under the reference architecture.
What this solution claims
ENI6MA replaces the part of PKI that keeps breaching you (the credentials that authorize requests) while certificates and mTLS can stay.ValidatedTransport identity (mTLS/PKI) coexists with request-level envelope authorization.
An envelope minted for one endpoint_id cannot authorize a different route.ShippingThe gate recomputes digests against its own endpoint_id and policy constants, not the client’s self-description.Holds under the reference architecture
SSO, federation, and PII
Enterprises already federate identity with SSO while still authorizing mutations with reusable tokens. SSO-PII is a design for keeping single sign-on and PII with your IdP while request authority still expires per call through ENI6MA proofs. It is specified on paper only: no runtime code, and not for purchase.
Enterprises already run OIDC, SAML, SCIM, and LDAP for who a person is. ENI6MA does not replace that authentication plane. The open design question is how to keep PII and directory attributes out of the authorization artifact while still binding an envelope to the exact action a federated user is about to take.
SSO-PII is specified on paper; no runtime code exists yet.Design targetREADME states no runtime code created yet.
Design badge. There is no evaluation, purchase, or get-started path yet. When a runtime ships, the public badge will update. Until then, treat this as design-only. Deploy Gate with your existing IdP for authentication.