Izanagi Protocol is post-quantum authentication infrastructure built on NIST FIPS-204 algorithms (ML-KEM and ML-DSA), with cryptographic session binding and a behavioral containment layer for unauthorized access attempts. Drop into your stack via Python REST API or Swift SDK.
NIST finalized the post-quantum standards in August 2024. Izanagi uses ML-KEM-{512,768,1024} for key encapsulation and ML-DSA-{44,65,87} for signatures, via the liboqs reference implementation. Algorithm selection is configuration-driven — rotation requires no code changes.
Every authentication token is cryptographically bound to its originating key-exchange session via kem_binding. Tokens that escape their session — whether through theft, accidental leakage, or replay — fail validation outside their origin context.
Failed authentication routes through a multi-stage state machine (Entry → Active → Deepening → Locked) that adapts to the access pattern. Containment complements the cryptographic guarantees rather than substituting for them — defense in depth, not security theater.
NIST has finalized the post-quantum standards. FIPS-203 (ML-KEM), FIPS-204 (ML-DSA), and FIPS-205 (SLH-DSA) were published in August 2024. The classical algorithms protecting most internet traffic today — RSA, ECDH, ECDSA — have a documented end date as a quantum threat materializes.
"Harvest now, decrypt later" is the operative threat model. Adversaries who capture encrypted traffic today can decrypt it once cryptographically-relevant quantum computers arrive. Long-lived sessions and signed artifacts issued in 2026 need to remain secure in 2030 and beyond.
Federal mandates are already in motion. CNSA 2.0 requires US national-security systems to begin post-quantum adoption immediately, with full transition deadlines between 2030 and 2035. Adjacent compliance regimes — CMMC, FedRAMP, regulated financial services — are integrating PQC requirements into their roadmaps.
Migrating production authentication infrastructure isn't a 90-day project. Teams that start the integration work now finish before the regulatory wave; teams that wait spend the mandate window scrambling.
Native Swift SDK shipping as a Swift Package. iOS 16+ / macOS 13+. Five-line integration with Keychain-backed token storage and biometric gating. Reach the secure-by-default bar without hand-rolling key exchange.
Python FastAPI service exposing a clean REST surface. Drops in alongside existing identity providers as a post-quantum layer, or replaces brittle session/token logic outright.
Defense contractors, financial services, healthcare. Teams whose FedRAMP, CMMC, or HIPAA roadmaps name PQC explicitly. Production crypto on NIST-standardized primitives with an audit trail.
Custody, wallets, KMS providers. Products where quantum threat is existential — not theoretical. PQC-first authentication and session binding for the workflows that can't tolerate token replay.
Client and server perform an ML-KEM handshake. The resulting shared secret derives the session's binding key — the cryptographic anchor for every token issued in this session.
The server signs a PQ1-format token with ML-DSA. The binding key is woven into the token's claims via constant-time HMAC, so the token can't be reused outside its originating session.
Verification re-derives the binding and compares in constant time. Failures route through the containment state machine — the system observes the access pattern rather than just returning 401.
We're inviting a small cohort of early customers to deploy Izanagi against real workloads. Beta participants get direct founder support, discounted pricing, and direct input into the roadmap. Tell us what you're building and we'll be in touch.
Izanagi Protocol is built by a single engineer with the deliberate discipline that implies. Every primitive — the post-quantum handshake, the kem_binding session model, the containment state machine, the Swift SDK — is in-house work, end-to-end. Direct line to the person who wrote the code is a feature, not a bug.