Kavacha
कवचZero-trust identity · a P9e Microsystems product
Kavacha exists because the systems this group builds do not fit the assumptions most IAM products make. A drone is not a laptop. A PLC is not a user. A satellite subsystem cannot re-authenticate through a browser. Kavacha treats humans, devices and services as three first-class identity classes with three appropriate mechanisms, and grants nothing on the basis of being inside the network.
- Written in
- Rust, from first principles
- Identity classes
- Human · Device · Service
- Deployment
- Self-hosted
No implicit internal trust. Every request is authenticated, authorised, rate-limited, risk-scored, attested where applicable, observed and audited — including the ones that came from inside.
How it fits together
Three identity classes, one decision point
A drone is not a laptop and a PLC is not a user, so each gets the mechanism that suits it. What none of them gets is trust for being inside the network — every request reaches the same policy decision, and every decision is recorded with the inputs that produced it.
What Kavacha does
Three identity classes, three mechanisms
Humans authenticate with OIDC, OAuth2 and WebAuthn. Devices carry X.509 certificates and use mTLS. Services hold SPIFFE identities. None of them inherits trust from network position.
Policy-based authorisation
Amazon Cedar policy sets, per-application and global, with explicit DENY overriding PERMIT. Just-in-time bindings and device attestation state are inputs to the policy decision, not side notes.
Post-quantum hybrid cryptography
Ed25519 with ML-DSA-65 for signatures, X25519 with ML-KEM-768 for key exchange, Argon2id for passwords, AES-256-GCM envelope encryption. Hybrid, so today's security does not depend on tomorrow's assumptions holding.
Threshold signing for operational commands
FROST-Ed25519 threshold signatures on commands that matter. An irreversible action requires a quorum by construction — the same principle as two-person approval on a spacecraft, enforced in cryptography rather than in process.
Built for devices that go offline
Drones, SCADA installations and field equipment lose their link routinely. Offline operation, device enrolment, attestation and signed firmware update are part of the identity model, not bolted on beside it.
Who Kavacha is built for
Not a list of industry names — what the product actually does differently in each.
Defence & aerospace
Device identity for platforms that operate away from the network, threshold signing on commands that cannot be undone, and an audit trail built for an export-controlled programme.
Critical infrastructure & utilities
Secure remote access to plant and field assets without flattening the OT network — attestation state and just-in-time bindings decide access, not a VPN and a shared account.
Regulated enterprise
Organisations that cannot put identity in someone else's cloud: self-hosted, auditable, with cryptography chosen to survive the archive as well as the session.
Deployed and embedded
- Vyovrinda — device identity and command authority for aircraft and spacecraft
- Smart Infrastructure — remote access to distributed field assets
- Samavāya — enterprise identity and audit
- Deployed self-hosted for customers who cannot use a cloud IAM
Where it actually stands
Self-hosted platform, in production inside the group and available to customers. Formal third-party security certification has not been completed — we will say so until it has.
We state maturity on every product page. A claim we cannot defend costs more than the work it wins.
Talk to us about Kavacha.
Deployment, embedding, evaluation licences — tell us the system it has to live inside.