# FedRAMP High for Kafka Without Replatforming TLDR - A federal customer asked for FedRAMP High, but the Kafka provider doesn't support it. - Moving everything into a separate, High-authorized environment is very expensive. - FedRAMP High is about data classification (PHI, PII, CUI). - Crypto is always the blocker: confidentiality, integrity, key custody, audit, and FIPS-grade encryption. - Solution: encrypt and sign records at the proxy layer inside your own environment. What do you do when you have a federal customer asking you for FedRAMP High and you depend on a Kafka provider? The standard practice is to _re-platform_: move to a provider that already has it, or stand up a separate, isolated environment for the government workload. These two solutions are going to take quite some time and cost a lot of money (capital and operational). What's the alternative? > Don't make the cloud itself FedRAMP High; make it irrelevant to the controls that drive the High requirement. How? We helped one of our customers with exactly this on their Kafka streaming platform, serving a U.S. federal agency. Their managed Kafka provider wasn't FedRAMP High, and *re-platforming was not an option*. We still got them to a point where FedRAMP's reviewers were comfortable signing off. They got there by changing as little as possible, by choosing *where to draw the cryptographic boundary.* ## A story of a federal customer and a Kafka that isn't High One of our customers is a healthcare company building a Kafka platform for sensitive patient data tied directly to individual identities. Kafka is the transport backbone, and Conduktor sits in front of it as the access and governance layer for the internal services and external partners consuming those topics. Their Kafka runs on a managed, cloud-hosted service, fully operated by a provider. A federal agency wants to use their platform, but it comes with a **FedRAMP High** requirement. The challenge: their managed Kafka provider is not FedRAMP High. And they don't want to get into self-hosting Kafka, which is a burden. > *"We're going to have to deploy a whole separate cloud just for this customer, and it's not going to be worth it."* > — Platform lead, healthcare company > [!NOTE] [FedRAMP High](https://www.fedramp.gov/) has 410 controls (FedRAMP Moderate has 323). A full authorization has historically run from several hundred thousand to a few million dollars and taken up to two years ([GAO, 2024](https://www.gao.gov/products/gao-24-106591)), though FedRAMP 20x now aims to cut that to weeks. You can run managed Kafka inside an isolated, High-authorized government region. It's costly but it will work. Or you can self-host Kafka inside one and own the entire environment yourself, which means taking on all of Kafka's operational weight and the uptime SLA (meaning hiring skilled people). For a high-availability federal workload, matching an established provider's availability (typically 99.99%) is extremely hard, and you can't miss that target for FedRAMP as availability is one of the main criteria. ## Do you actually need to be that High? What is driving the "High" requirement? It can be a hard contractual floor or a "let's be safe" call. In our story, it came down to **data classification**. - **CUI** (Controlled Unclassified Information): usually the real driver of the High-vs-Moderate question. Basic CUI often maps to Moderate. CUI Specified, mission sensitivity, agency policy, or an explicit contract clause can push the requirement to High. - **PHI** (protected health information): patient health data tied to identity, generally covered by HIPAA, but PHI in a federal-facing system pulls it inside the FedRAMP boundary. - **PII** (personally identifiable information): provider and agency-staff identities, audit-trail identities. On its own, usually **Moderate**. Naming the data class tells you which controls apply. For FedRAMP High, only a handful do, and the fix is most often encryption: confidentiality and integrity. What actually makes a cloud non-compliant is almost always the cryptography. ## FedRAMP and the CIA triad The CIA triad means: Confidentiality, Integrity, Availability. What's the link with FedRAMP? FedRAMP High is often used as a shortcut for all three. But not all three have to be solved in the provider's environment. Why? You can handle confidentiality and integrity inside your own trust boundary. Encrypt the data before it reaches the provider. Keep the keys on your side. Audit everything. Use approved cryptography. At that point, the provider no longer needs to be trusted to read or tamper with the data, because those controls happen before the data reaches it. The only hard part left for the provider is keeping Kafka running at the uptime your federal customer expects. So "FedRAMP High" is often shorthand for three questions: 1. **Key custody:** who holds the encryption keys, and can the provider read your data? 2. **Audit-log control:** can you prove who did what, in a log *you* own? 3. **FIPS-grade crypto:** is the cryptography itself up to federal standard? Frame it as those three controls instead of one giant certification, and each is something you can handle in _your own environment_. ## Make Kafka a dumb pipe In this case, you treat the Kafka provider as a dumb pipe. You keep the cryptographic boundary inside *your* environment, with keys that never leave and signatures created and verified at the edge for integrity (on the consumer side). Kafka only ever sees **ciphertext it can't read and can't tamper with.** It doesn't need to be FedRAMP High for confidentiality and integrity specifically, because you handled those controls before the data ever reached it. An analogy we use is: **TLS, but persistent.** TLS garbles bytes on the wire so anyone in the middle sees nonsense; here the bytes stay garbled at rest in Kafka, too. Unreadable in transit *and* at rest. > [!NOTE] This is the posture the federal government adopted for itself. NIST's Zero Trust Architecture ([SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final)) protects "resources... not network segments," and the federal zero-trust mandate ([OMB M-22-09](https://zerotrust.cyber.gov/downloads/M-22-09%20Federal%20Zero%20Trust%20Strategy.pdf)) requires agencies to encrypt their traffic. "Protect the data, not the perimeter" is the rule. ## How does Conduktor Gateway help? Conduktor Gateway is an enterprise Kafka proxy that sits transparently between Kafka and its applications. There is no need to do anything on the client side, no SDK, and nothing to do on the broker side. Producers and consumers connect to it exactly as they would to a Kafka cluster, it's totally seamless. The difference now is that the Gateway applies policy to every record as it flows through and forwards it on. This is what lets it own a cryptographic boundary and protect the data before Kafka ever gets it. Here's how the two compare. With Conduktor, you own the cryptographic boundary: ## Which Gateway features help with FedRAMP? - **[Payload or Field-Level Encryption](https://docs.conduktor.io/guide/use-cases/kafka-encryption).** The Gateway encrypts data on produce (full payload or field-level encryption) and you can selectively decide which service account can read them. The keys live in your own key-management service (Vault, Azure Key Vault, AWS KMS, GCP KMS, Fortanix). - **[Record Integrity & Anti-Tampering](https://docs.conduktor.io/guide/reference/data-security#message-integrity-interceptor).** The Gateway signs each record on produce, and verifies that signature before forwarding it to a consumer. If a record was altered in the cloud, or written to Kafka *around* the Gateway, it fails verification and is discarded. Tampering in transit or at rest is now detectable. > [!NOTE] TLDR: *encrypt* and *sign* on the way in, verify and decrypt on the way out. Kafka in the middle only gets signed ciphertext. Note it's **provider-agnostic**: whether your Kafka is managed SaaS, self-hosted, or mid-migration. When you have it installed, you can cover a lot more of the FedRAMP requirements: - Have your own [**audit-log**](https://docs.conduktor.io/guide/tutorials/configure-audit-log-topic#kafka-audit-log-topic-configuration) with specific retention to a topic you own and control - Define a complete [**authentication and authorization**](https://docs.conduktor.io/guide/conduktor-concepts/gateway-authentication-authorization) abstraction layer - Introduce [**data masking at the field-level**](https://docs.conduktor.io/guide/use-cases/kafka-encryption) - [**Tokenize**](https://docs.conduktor.io/guide/reference/data-security#tokenization) data to enable queries while hiding sensitive data. One tool, one place to enforce all of them. > [!NOTE] [Interestingly enough](https://www.hhs.gov/hipaa/for-professionals/faq/2076/if-a-csp-stores-only-encrypted-ephi-and-does-not-have-a-decryption-key-is-it-a-hipaa-business-associate/index.html), when breached ePHI is encrypted consistent with HIPAA standards and the decryption key wasn't compromised, the incident falls within the breach "safe harbor", and the provider isn't required to report it. The key MUST stay out of the provider's reach. The [American Hospital Association found](https://www.aha.org/news/aha-cyber-intel/2025-10-07-2025-cybersecurity-year-review-part-one-breaches-and-defensive-measures) that across 2024–2025 healthcare breaches, **100% of the hacked data was effectively unencrypted**, usually because the data was encrypted but the key sat right beside it. ## FedRAMP + Conduktor Gateway = Approved The team took this into their FedRAMP discussion with their prospective Third-Party Assessment Organization (3PAO), and came back with **high confidence the approach would be approved**: keep the SaaS cloud, encrypt the payloads at the Conduktor Gateway boundary. They were comfortable with ciphertext moving into and sitting in the cloud, *as long as the data path is documented*: the topic strategy, where data is and isn't encrypted, and which standards apply. --- *Nothing in this post is a compliance guarantee. FedRAMP determinations are made by your authorizing official and your 3PAO, and the same case can be assessed differently depending on who reviews it and the specifics of your data. Treat this as an architectural pattern to evaluate with your security and compliance teams, not as a certification.* **Related**: [Kafka in Production: 11 Pitfalls You Should Avoid →](https://www.conduktor.io/blog/kafka-production-pitfalls) · [Conduktor Gateway →](https://docs.conduktor.io/guide/conduktor-concepts/interceptors) · [Traffic Control & Governance Policies →](https://docs.conduktor.io/guide/conduktor-concepts/traffic-control-policies)