We engineered to the FedRAMP Moderate standard before we had a customer¶
Security posture in a young software company usually arrives in a particular order. First the product, then the customers, then the enterprise buyer who sends a 300-question spreadsheet, then the engineer whose job for the next two quarters is to make the answers true. Cryptography gets swapped for a validated module. Logging gets extended to cover what the framework asks for. A supply-chain story is assembled from whatever the build pipeline happened to do.
That order is rational for most products. It is the wrong order for ours. Kanonik exists to produce a record that an auditor can trust. A product like that cannot have a security posture it added later; the posture is the product. So we chose a standard early, FedRAMP Moderate, and built to it from the first commit.
What "built to the standard" means in practice¶
Cryptography first. Every security-critical path in Kanonik uses FIPS 140-3 validated cryptography. That covers the signatures on approval links, the hash chain and its signed root, the per-tenant data encryption keys, the TLS between our own services, and the key derivation behind all of it. There is no non-validated path for these operations to fall back to, because we did not build one.
Audit logging is aligned to NIST 800-53 from the start. Every action that touches a tenant's record produces a structured event with the actor, the tenant, a trace identifier, and the outcome. The events are the product's memory, not a compliance afterthought, so there was never a version of Kanonik that did not log this way.
The supply chain is signed end to end. Every container image is signed before release and carries a software bill of materials. Vulnerability scanning runs on the source and on the image, and a high-severity finding blocks the merge rather than filing a ticket. Infrastructure is defined as code and deployed through a GitOps pipeline, so there are no manual production changes to reconstruct after the fact.
Tenants are isolated cryptographically, not just logically. Each tenant's data is encrypted at rest with its own key, and that key is wrapped by a tenant key held in a vault that no application process can read directly. Row-level security enforces the boundary in the database as well, so an application bug cannot cross it.
The system boundary is one boundary. Three services, one deployment, one set of network controls, mutual TLS between every internal hop. An authorisation package needs a system you can draw a line around. We drew the line before there was anything inside it.
Built right from day one, not retrofitted¶
Kanonik is engineered to the FedRAMP Moderate standard from the first commit. That is a provable statement, and every part of it is above: FIPS 140-3 validated cryptography in every security-critical path, NIST 800-53-aligned audit logging, a signed supply chain with a bill of materials on every image, per-tenant cryptographic isolation, one system boundary with mutual TLS inside it. None of it was added for a questionnaire. It is the architecture, and it is the same architecture on the Solo plan as it will be in an authorisation package. Authorisation itself is a later step on our roadmap; the engineering it will document is already running.
Why it matters if you are not a federal buyer¶
Most of our customers will never need FedRAMP. They will need SOC 2, or ISO 27001, or a bank's vendor questionnaire. The standard we chose is the one that makes those easy to answer, because it is stricter than any of them on the questions that actually get asked: what crypto, what logging, what isolation, what supply-chain controls, who can touch production.
When a compliance product cannot answer those questions well about itself, its customers should wonder what else it has deferred. Ours were answered before the first tenant signed up.
Kanonik is new-gen GRC for teams that can't afford the GRC monsters and shouldn't have to. Try Kanonik free for 14 days at kanonik.ai.