Apache Kafka Security Review
Kafka treats authentication, encryption and authorisation as separate switches, shipped off by default. We test your listeners, topic ACLs, Connect endpoints and Schema Registry against what you have switched on. CREST-certified testers, fixed price from £2,620 for a 2-day single-system scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
Apache Kafka’s own documentation states that security is optional and non-secured clusters are supported, with authentication, encryption and authorisation each switched on independently of the other two.
Why Kafka’s authentication, encryption and authorisation are three separate switches
Every Kafka listener is mapped to a security protocol independently through listener.security.protocol.map, and Kafka’s own listener configuration documentation states plainly that the PLAINTEXT protocol provides no security at all, and that the inter-broker listener defaults to PLAINTEXT too unless a different one is named. Client authentication is a further, separate choice between SASL mechanisms such as GSSAPI, PLAIN, SCRAM and OAUTHBEARER, or mutual TLS through ssl.client.auth, which Kafka’s SSL configuration guide notes defaults to no certificate check unless set to requested or required, and calls the requested setting a false sense of security since a client without a certificate still connects.
Authorisation is a third, separate switch again. The authorizer.class.name property that turns it on defaults to an empty string, and Kafka’s security overview states outright that security is optional and non-secured clusters are supported. Once an authorizer is configured, its default behaviour denies a resource with no matching ACL to everyone except the accounts listed in super.users, but setting allow.everyone.if.no.acl.found=true reverses that default for every resource without an ACL, and a super user bypasses ACL checks entirely rather than appearing in one.
Kafka Connect and Schema Registry sit outside this model entirely. Connect’s own user guide states that its REST API is unsecured by default and that anyone who can reach it can start and stop connectors, while Schema Registry adds its own separate authentication and authorisation layer on top of whatever the Kafka cluster underneath already enforces. On Confluent Cloud and Amazon MSK, the provider takes over the infrastructure under its own shared responsibility model, leaving your roles, ACLs and client authentication as what we test. For the wider family this scope splits from, see our NoSQL, cache and streaming security review.
SCOPE
What we review in a Kafka cluster
Listener Configuration and PLAINTEXT Exposure
Kafka’s listener.security.protocol.map assigns PLAINTEXT, SSL, SASL_PLAINTEXT or SASL_SSL to each named listener independently, and Kafka’s documentation states plainly that the plaintext protocol provides no security. The inter-broker listener defaults to PLAINTEXT too, through security.inter.broker.protocol, unless inter.broker.listener.name points to something else. We check what every listener on every broker is actually mapped to, including inter-broker traffic, against what your cluster is meant to require.
SASL Authentication and Mutual TLS
Kafka supports SASL/GSSAPI (Kerberos), SASL/PLAIN, SASL/SCRAM and SASL/OAUTHBEARER as client authentication mechanisms, and separately supports mutual TLS through ssl.client.auth, which defaults to no client certificate check unless set to requested or required, with Kafka’s own guidance calling requested a false sense of security since a misconfigured client without a certificate still connects. We test which mechanism each listener actually enforces and whether a client can reach a broker without presenting valid credentials at all.
Encryption In Transit Between Brokers and Clients
Encryption depends entirely on which security protocol a listener uses: SSL and SASL_SSL encrypt traffic, PLAINTEXT and SASL_PLAINTEXT do not, and Kafka’s own security overview notes that a mix of encrypted and unencrypted clients is a supported configuration rather than an error the broker will flag. We test every listener, plus the separate inter-broker and controller connections, for which of them actually carry TLS.
Topic and Consumer Group ACLs
Once an authorizer such as StandardAuthorizer is configured, Kafka’s default behaviour denies a resource to everyone except super users when no ACL matches it, but setting allow.everyone.if.no.acl.found=true reverses that, opening every topic and consumer group without an explicit ACL to any authenticated principal. We test the ACLs actually granted against every topic, consumer group and transactional ID in scope, and check whether allow.everyone.if.no.acl.found has been left enabled.
Super Users and Authorizer Bypass
A principal listed in super.users, configured as a semicolon-delimited list such as User:Bob;User:Alice, bypasses ACL checks entirely rather than being granted a broad ACL, so it never shows up however the ACL list itself is audited. We identify every super user configured on the cluster and confirm each one still needs that level of access.
Kafka Connect REST API and Connector Credentials
Kafka Connect’s own documentation states that its REST API is unsecured by default and allows anyone who can reach it to start and stop connectors, adding that this makes arbitrary code execution straightforward since connectors run custom plugin code. Connector configuration can load credentials from outside the config file through the config.providers mechanism, and since Kafka 4.2.0 the documentation recommends setting connector.client.config.override.policy to Allowlist rather than leaving client overrides open. We test whether the REST API is reachable without authentication, what a connector’s configuration exposes, and how any provider-backed credentials are stored.
Schema Registry Authentication and Authorization
Confluent’s documentation lists TLS encryption, OAuth, mutual TLS and SASL as supported authentication methods for Schema Registry, alongside role-based access control or the Schema Registry ACL Authorizer for authorisation, each layered on top of a secured Kafka cluster rather than replacing it. The Schema Registry service principal itself needs read, write and describe access scoped to the internal _schemas topic, no more. We test which of these features your deployment has enabled and whether the service principal’s own ACLs are broader than that.
Admin, Monitoring and Management UI Exposure
Cluster managers, monitoring dashboards and Schema Registry UIs run as separate web applications, with their own authentication configured independently of the broker’s own listener security. We check every admin and monitoring interface reachable in scope for authentication, and for what topic contents, consumer lag or broker configuration it exposes to an unauthenticated visitor.
ZooKeeper and KRaft Controller Exposure
Kafka’s documentation confirms that migrating a ZooKeeper-based cluster to KRaft requires passing through a bridge release, with Kafka 3.9 as the last one, so an older estate may still depend on ZooKeeper for cluster metadata and needs it secured in its own right. In KRaft mode, the controller listener defined by controller.listener.names must be a separate listener from the one used for inter-broker traffic, and Kafka’s documentation recommends isolating it since ordinary clients never need to reach it. We test whichever metadata layer your cluster actually runs, and whether the controller or ZooKeeper endpoints are reachable from anywhere they should not be.
Managed Kafka: Confluent Cloud and Amazon MSK
On Confluent Cloud, Confluent’s documentation describes SSO, OAuth/OIDC and mutual TLS for authentication and role-based access control or ACLs for authorisation, with the provider responsible for the underlying infrastructure under its published shared responsibility model. On Amazon MSK, AWS documents IAM access control, TLS or SASL/SCRAM client authentication, with credentials optionally held in AWS Secrets Manager, and standard Kafka ACLs for authorisation, again against AWS’s own split between security of the cloud and security in the cloud. We test the roles, ACLs and client authentication you control on whichever platform you run, confirming the current provider boundary with you during scoping.
OUR PROCESS
Apache Kafka Security Review: From Scope to Attestation
Scope and Access
We agree which brokers, topics, Kafka Connect clusters and Schema Registry instances are in scope, plus at least one authenticated principal per privilege tier and, where relevant, read-only access to your Confluent Cloud or Amazon MSK console.
Configuration and Permission Mapping
We map every listener’s security protocol, SASL mechanism and TLS configuration, then every topic, consumer group and connector ACL, super user and Connect REST endpoint, against who is meant to hold that access.
Manual Testing
A CREST-certified tester manually tests authentication and encryption on every listener, authorisation gaps in topic and consumer group ACLs, and Kafka Connect and Schema Registry exposure, chaining findings where they compound.
Attestation and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST Kafka pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent Apache Kafka Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
2 to 3 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote3 to 4 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote4 to 6 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test Kafka For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From Apache Kafka Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our Kafka cluster?
We need at least one authenticated principal for every privilege tier in scope, from an ordinary producer or consumer client through to an account that can query ACLs, connector configurations and Schema Registry subjects for configuration review. Where the cluster runs on Confluent Cloud or Amazon MSK, read-only console or IAM access speeds up configuration review but is not required to run the manual test itself.
Will testing touch live data or production topics?
We test the brokers, topics and connectors you nominate, working against your actual ACLs, listener configuration and Connect setup rather than a copy, so we agree exclusions such as destructive administrative commands, topic deletion or production-only connectors before testing starts. We do not run destructive tests or export real message payloads without that agreement in writing.
How long does a Kafka security review take?
A single cluster with a small number of brokers, topics and connectors in scope sits in our 2-day single-system scope, with a report typically landing around 5 working days after kickoff. Multiple clusters, a large number of Connect connectors, or a mix of self-hosted and managed environments moves into a larger scope with more testing days.
Do you test self-hosted Kafka and managed platforms such as Confluent Cloud or Amazon MSK the same way?
The questions are the same: listener authentication and encryption, ACLs, super users, and Connect and Schema Registry exposure. What differs is the boundary, since Confluent Cloud and Amazon MSK both take over the underlying infrastructure under their own shared responsibility models, so we confirm during scoping exactly what you control on your plan and test to that boundary.
Do you test Kafka Connect connectors and Schema Registry?
Yes, reviewing whether the Connect REST API is authenticated, what a connector’s configuration exposes and how Schema Registry’s own authentication and authorisation are configured is part of the standard engagement wherever either is deployed. Testing a specific connector’s own closed-source code, rather than how it has been configured and exposed, is out of scope unless separately agreed.
What is out of scope for a single-system Kafka review?
We never test the underlying host, hypervisor or infrastructure of a managed Kafka service, or Kafka’s own source code, and a separate connected system such as an identity provider used for OAUTHBEARER tokens or a backup platform is scoped and quoted separately. We test the listener configuration, authentication, ACLs, and Connect and Schema Registry configuration on the cluster and connectors you nominate.
Do your cloud provider’s rules restrict what you can test?
It depends on the platform. AWS publishes a list of services customers can assess without prior approval, and Amazon MSK is not one of the services named on that list, so we confirm AWS’s current policy for your specific cluster during scoping. Confluent does not publish an equivalent public list for Confluent Cloud, so we confirm its current customer testing terms with you before testing starts.
Are your testers CREST certified?
Yes. Every Kafka engagement is carried out by UK-based, CREST-certified testers, and your report and attestation letter are recognised by auditors and insurers accordingly.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your Kafka security review
Kafka treats authentication, encryption and authorisation as separate switches, shipped off by default. We test your listeners, topic ACLs, Connect endpoints and Schema Registry against what you have switched on. CREST-certified testers, fixed price from £2,620 for a 2-day single-system scope, quoted within 24 hours.
