Which PCI DSS requirements Apache APISIX helps evidence for public-facing web applications
If you are a merchant, processor or service provider with internet-facing payment pages or payment APIs, an assessor will want to see two things at the edge: an automated technical solution that continually detects and prevents web-based attacks under Requirement 6.4.2, and strong cryptography protecting PAN in transit under Requirement 4.2.1. Apache APISIX can sit at that edge as the API gateway and supply both kinds of evidence. It does not cover Requirement 6.4.3, which concerns management of payment page scripts in the browser, and it does not define your assessment scope or replace the judgment of your Qualified Security Assessor (QSA). Whether a Self-Assessment Questionnaire D (SAQ D) or a Report on Compliance (ROC) applies to you depends on your entity type and payment brand rules, so confirm that with your acquirer or QSA before you design the controls.
The practical question is which gateway components will be named in your evidence. For 6.4.2, the assessor will look at the attack-prevention layer in front of each public route: which plugins inspect requests, how they are enabled per route, and how detections are logged and reviewed. For 4.2.1, the focus moves to the TLS listener configuration, the protocol versions and cipher suites allowed on client traffic, certificate validity and revocation handling, and whether any fallback to older protocols exists. APISIX does not make these decisions for you. Your team must decide which protections are enforced at the gateway and which remain with an upstream web application firewall, and must record that split so the assessor can trace each requirement to a named control.
DeployOpen prepares the configuration, test results and evidence packs that support these requirements, and your QSA or the relevant assessment body decides whether they are sufficient. DeployOpen does not issue audit reports, attestations or certifications. Before the build starts, ask your QSA which evidence formats they accept, confirm which PCI DSS version your assessment uses, and confirm the APISIX version and plugin set you intend to run, since release names and defaults change over time.
Mapping PCI DSS 6.4.2 and 4.2.1 to APISIX capabilities and configuration
This table maps the two PCI DSS v4.x requirements that an APISIX gateway can help evidence, along with the one that sits outside its scope. Read each row as a question to answer in your own environment: what the requirement asks, what APISIX can contribute, and what you must configure and test before an assessor sees it. Rule coverage and TLS policy always need your own verification.
| Requirement | Platform capability | Configuration needed |
|---|---|---|
| 6.4.2: Automated technical solution that continually detects and prevents web-based attacks (effective 31 March 2025, superseding 6.4.1) | APISIX can sit in front of public web applications and forward traffic through a WAF integration or built-in security plugins, such as the documented IP restriction and request validation plugins. | Place APISIX on every public route, set the WAF or plugin mode to block (not log only), tune rules to your applications, and confirm rule coverage through your own testing. |
| 4.2.1: Strong cryptography and security protocols for PAN over open, public networks | APISIX terminates TLS for client traffic on HTTPS and HTTP/3 listeners, and its SSL objects control certificates, keys and protocol versions. | Disable SSL and early TLS, allow only approved protocol versions and cipher suites, and load trusted, unexpired certificates from your key management process. |
| 4.2.1: Certificates confirmed valid, not expired and not revoked | APISIX serves the certificates you load. It does not itself confirm revocation status for every certificate in your estate. | Document certificate issuance, renewal and revocation checks, and confirm how and where your team verifies revocation status before relying on the gateway. |
| 4.2.1: No fallback to insecure versions or configurations | Protocol and cipher settings on the gateway determine what clients can negotiate. Defaults can change between releases. | Pin the TLS policy in version-controlled configuration, retest after each APISIX upgrade, and scan the public endpoint to confirm no weaker version is accepted. |
| Logs and configuration evidence for 6.4.2 and 4.2.1 | APISIX access and error logs and plugin configuration can be exported to your logging system, and the Admin API can be restricted. | Ship gateway logs to protected storage, keep route and plugin configuration in version control with change records, and restrict who can change the Admin API. |
| 6.4.3: Management of payment page scripts | Out of scope for this gateway control. APISIX does not manage scripts that run in the customer's browser on payment pages. | Address 6.4.3 with your payment page inventory and script controls, and cover it in your assessment separately from the gateway. |
Configuring TLS and attack prevention for PAN in transit
Requirement 4.2.1 expects strong cryptography and security protocols for PAN sent over open, public networks. The PCI SSC has said the standard does not name required TLS versions, but SSL and early TLS (at minimum TLS 1.0 and 1.1) do not meet its definition of strong cryptography, so the gateway should negotiate only modern protocol versions and approved cipher suites. In APISIX, this is set on the TLS listener and on the SSL objects that hold certificates, so the policy has to be confirmed in each release you run.
- Protocol and cipher policy: Define the allowed protocol versions and cipher suites in the gateway configuration, and disable SSL and TLS 1.0 and 1.1 explicitly rather than relying on defaults.
- No fallback: Confirm that the gateway and any upstream client cannot negotiate down to an insecure version or configuration.
- Certificate validity: Accept only certificates from trusted authorities or your own trusted chain, and check that they are not expired.
- Revocation handling: Decide how revoked certificates are detected, through OCSP or CRL checks where your certificate authority supports them, and document the result.
- Key ownership: Record who holds private keys, where they are stored and how rotation is triggered.
Before assessment, test the listener with a TLS scanner from outside the cardholder data environment and keep the output as evidence, and confirm the exact default protocol and cipher settings against the APISIX release in use.
Requirement 6.4.2 expects an automated technical solution that continually detects and prevents web-based attacks on public-facing applications. A gateway can provide that layer by inspecting requests before they reach the application, but it works only when its rules are enabled, tuned and tested against the application behind it. APISIX can integrate with a web application firewall and applies request limits and header rules, and the design should show how each control stops attacks rather than only logging them.
- WAF integration: Choose the WAF component, route the public-facing paths through it and document which rule sets are active and how they are updated.
- Request limits: Set maximum body sizes, header sizes and rate limits per route, so that oversized or abusive requests are rejected at the gateway.
- Header trust: Decide which client-supplied headers the gateway forwards, strip or overwrite headers such as forwarded client addresses, and prevent clients from spoofing internal identity headers.
- Blocking and alerting: Confirm that detected attacks are blocked as well as recorded, and that alerts reach the team that responds.
- Testing: Run authenticated and unauthenticated attack tests against the public routes, check that blocked requests never reach the upstream service, and keep the results with the rule configuration.
Confirm the exact WAF integration options and default limits for your APISIX release, because the plugin set and defaults change between versions.
Assessors will ask how the gateway settings were chosen, how they are kept in force and how you can show that they work. The evidence for both requirements is largely the same: current configuration, test results and records of change. Keeping the gateway configuration under version control and tying each change to an approved request makes it possible to show the state of the controls on any date within the assessment period.
- Configuration baseline: Store the TLS, WAF and limit settings in version control, with a named owner and a review date.
- Change records: Link each change to a ticket, an approval and a test run, so the history can be sampled.
- Scan and test output: Keep the TLS scan results and the attack-prevention test results from each release cycle.
- Gateway logs: Retain access and security logs for the period the assessor requests, and protect them from modification.
- Scope boundaries: Document which gateway components are in the cardholder data environment and which are connected to it.
Ask your Qualified Security Assessor which evidence format they expect, and confirm the retention periods with your own policy before relying on them.
Logs and configuration evidence assessors ask for from the gateway
Assessors look for records that show the gateway protected cardholder traffic and that changes to it were controlled. Each card below names one evidence set, how to keep it, and what to check, but the assessor decides whether the evidence is sufficient for the requirement it supports.
Access and error logs with retention
Keep APISIX access and error logs from every public route, including the request path, status code, timestamp, client address and upstream response, and ship them to a store the gateway team cannot edit. Confirm that the log format omits cardholder data and authentication secrets, since a log that captures PAN creates a new scope problem. Set a retention period with the assessor and your payment brand in mind, and test that a sample of entries can be pulled for a given date and route.
TLS configuration exports and certificate inventory
Export the TLS settings APISIX applies to each listener, including protocol versions, cipher suites and certificate chains, and keep dated copies. Pair the export with an inventory of every certificate, its issuer, expiry date and the systems that use it, so an assessor can confirm that expired or revoked certificates are not accepted. Re-export after each change to show the configuration in force at any given time.
Versioned route and plugin configuration in Git
Store route, upstream, consumer and plugin definitions as files in Git, with the web attack prevention plugin settings included. Every change should go through a reviewed merge request that links to a change ticket, so the history shows what was changed, by whom, and who approved it. For standalone deployments, the apisix.yaml file is the artifact to version. Confirm that production runs only from tagged commits.
Admin access and change audit trails
Record who reached the Admin API, when, and from which network, and restrict that access to a small administrative group through named accounts. Keep the admin API off public networks and retain the audit records in a system separate from the gateway. Review the list of administrators at a set interval and record the removals. Ask the assessor which evidence they will sample to confirm that configuration changes were authorized.
Attack-prevention alert and blocked-request records
Keep records of every request the web attack prevention layer blocked, along with the rule that triggered, the time and the affected route. Alerts should reach a team that acts on them, and the response to each should be documented. These records are the main evidence that the solution detects and prevents web-based attacks continually, so confirm that the rule set is updated and that blocking events are not silently dropped when log shipping fails.
Periodic review records
Document a recurring review of gateway configuration, rule effectiveness, certificate status and admin accounts, with a named reviewer, the date, the findings and the follow-up tickets. Reviews show that controls are maintained after go-live, not just configured once. The review schedule and the depth of each review are decisions for your assessment team, so agree them before the first assessment cycle.
Sequence for a PCI-scoped APISIX rollout
This sequence takes APISIX from a scoping decision to a gateway whose configuration, attack prevention, TLS and logs can be shown to an assessor. Each step produces an artifact that the next step depends on, so the order matters more than the individual tasks.
Confirm scope and the CDE boundary
Before any build work, the organization and its Qualified Security Assessor agree which systems store, process or transmit cardholder data and which systems could affect that environment. The gateway's position relative to the cardholder data environment (CDE) is decided here, because it determines whether APISIX itself falls in scope. Ask the QSA to confirm the boundary in writing, and record the data flows that cross it. The step is complete when the scope statement and a data flow diagram are signed off by the people who will be assessed against them.
Choose the deployment mode
Select traditional, decoupled or standalone mode based on how the gateway team manages configuration and where etcd can run inside the scoped network. Decoupled and traditional modes depend on a shared etcd cluster, which then becomes another component that needs access control and evidence. Standalone mode keeps configuration in a YAML or JSON file, which is easier to version but places more weight on how that file is reviewed and deployed. The output is a written architecture decision that names the components inside the CDE and the ones outside it.
Isolate the Admin API
The Admin API, which listens on port 9180 in traditional mode, controls every route and plugin, so it must not share a network path with public client traffic. Place it on a segregated management network, restrict access to named administrators and automation accounts, and change the default admin key before any environment is exposed. Confirm the restriction by testing from an untrusted segment and confirming the connection fails. Keep the test result, the firewall rule set and the list of accounts with Admin API access, since assessors commonly ask for them.
Configure TLS and certificates
Configure HTTPS on the client-facing listener so that PAN crosses open, public networks only under strong cryptography, as Requirement 4.2.1 requires. Disable SSL and TLS 1.0 and 1.1, since the PCI SSC does not accept them as strong cryptography, and confirm the remaining protocol and cipher list against the organization's cryptography standard. Document certificate issuance, renewal and revocation checks, and confirm that expired or revoked certificates are rejected. The step closes with a scan of the public listener showing only the approved protocols and an inventory of certificates with owners and expiry dates.
Enable the attack-prevention layer
Enable the automated technical solution that continually detects and prevents web-based attacks, which is the basis for Requirement 6.4.2. In APISIX this typically means placing a web application firewall or equivalent plugin in front of the protected routes, applying a tuned rule set, and setting request size limits and header trust rules at the gateway. Confirm the chosen layer is in the request path for every public route, not only some of them. The output is a route inventory showing which routes the layer protects, the rule version in use, and the alert or block mode each route runs in.
Define logging and retention
Set the access logs and gateway logs to capture the fields an assessor will check, such as timestamp, client address, route, authentication outcome and blocked requests, while keeping PAN and other sensitive data out of log output. Forward logs to a protected store with access control and agree a retention period with the QSA and the organization's policy owner. Test log integrity by generating a known request and confirming it appears in the central store. The step is complete when a sample of log entries, the retention setting and the access list for the log store are saved as evidence.
Version configuration and control changes
Store routes, plugins, upstreams and certificate references in version control, and deploy them through a reviewed change process rather than by editing the live Admin API by hand. Each change should record who approved it, what changed and which tests ran before release. Confirm that production configuration matches the reviewed repository, since drift between the two is a common finding. The output is a repository history, a change procedure and a sample of approved changes that can be traced to a deployment.
Run validation testing
Test the gateway against the controls it is meant to provide: confirm that the Admin API is unreachable from public segments, that weak protocols fail the handshake, that the attack-prevention layer blocks a set of test payloads on protected routes, and that logs capture those events. Where the organization uses external testers, agree their scope in writing and keep their reports. Record each test with the expected result, the actual result and the person who verified it. Any failure reopens the earlier step that caused it before the gateway goes live.
Collect evidence for the assessment
Assemble the package the assessor will request: the scope and boundary statement, the architecture decision, network and firewall rules for the Admin API, TLS scan results, certificate inventory, attack-prevention configuration, log samples and retention settings, the configuration repository history and the validation test records. Map each artifact to the requirement it supports, including 4.2.1 and 6.4.2, and keep a copy under change control. The assessment outcome itself comes from the QSA's Report on Compliance or the organization's Self-Assessment Questionnaire, since DeployOpen prepares evidence but does not issue validation.
What APISIX does not cover for PCI DSS
An APISIX gateway addresses a narrow part of PCI DSS v4.x. The cards below mark the controls it cannot satisfy on its own, so the assessment scope and evidence plan account for them before the gateway goes live.
Payment page script management
Requirement 6.4.3 covers scripts loaded on payment pages, including inventory, authorization, integrity checks and monitoring. A gateway can route and filter requests but does not see what a browser runs once the page loads. Confirm which team owns the script inventory and how integrity evidence will be captured, and check the PCI SSC FAQ on 6.4.3 before scoping the page.
Application code and secure development
Requirement 6.2 and related controls cover secure coding, code review and vulnerability management in the application itself. A WAF-style layer reduces exposure to known attack patterns but does not fix flaws in your code. Plan separate evidence for secure development practices, code review records and vulnerability remediation timelines.
The rest of the CDE and network controls
Firewalls, network segmentation, internal access, logging of other systems and the wider cardholder data environment remain outside the gateway. APISIX sits at the edge of the application, so the assessor will still test the surrounding network. Map every system that stores, processes or transmits cardholder data before defining the gateway's place in that scope.
Key management for stored PAN
Requirement 3 governs how stored primary account numbers are protected, including encryption and key lifecycle. APISIX can terminate TLS and store its own certificates, but it does not manage the keys that encrypt PAN at rest. Confirm where those keys live, who rotates them and how custody is documented.
Customized approach documentation
If you meet a requirement through the customized approach instead of the defined approach, the targeted risk analysis and the documented objective are your responsibility. A gateway control does not carry that documentation with it. Write the objective, the risk analysis and the test evidence yourself, and confirm with your assessor whether the approach fits your entity.
No certificate or attestation from the project
The Apache APISIX project and DeployOpen do not issue a Report on Compliance, Attestation of Compliance or certificate. A Qualified Security Assessor or your self-assessment produces those documents, and certificates are not recognized as validation. Treat APISIX as a source of configuration and log evidence, not as a compliance outcome.
Questions buyers ask before using a partner for APISIX and PCI DSS
What drives the cost of an APISIX PCI DSS engagement?
The main drivers are the number of routes and domains in the cardholder data environment, how many of those routes carry PAN, whether an existing WAF or CDN must be integrated or replaced, the number of log destinations, and how many environments (test, staging, production) need the same configuration. Your own team's familiarity with APISIX, Kubernetes and etcd also changes the effort. Costs are split between one-time work (scoping, design, build, testing, documentation) and recurring work (upgrades, rule tuning, log review, and evidence collection for each assessment cycle). DeployOpen works to a written, fixed scope, so ask for a quote that lists routes, environments, plugins, integrations and evidence deliverables separately.
How long does it take to reach a defensible APISIX configuration?
The timeline depends on the scope you agree in writing, not on a fixed template. Time is consumed by the architecture review, the cardholder data flow mapping, the rule set for web attack prevention, the TLS policy and certificate work, test cycles against your real traffic patterns, and handover of configuration and evidence. Plan for an assessor review window before go-live if your QSA needs to see the design first. Ask any partner to show the milestones and which of them depend on your approvals, such as change windows and certificate issuance.
What must our team provide before the work starts?
Before work starts, you should be ready to provide:
- A current architecture diagram showing where cardholder data enters, moves through and leaves your environment, including any CDN, WAF, load balancer and payment service provider.
- The inventory of public routes, hostnames and upstream services, and which of them handle PAN or sensitive authentication data.
- Certificate authority details, certificate issuance process and the private keys or key custody model you use.
- The name and contact of your Qualified Security Assessor, so the design can be reviewed against their expectations early.
- The log destinations and retention rules your SIEM or log platform requires, plus access rules for who may view gateway logs.
Confirm each item with your own team and your assessor, because the answers change the design.
Can our internal team implement APISIX for PCI DSS without a partner?
Yes, an internal team can implement APISIX if it has engineers who can run the gateway, manage TLS and certificates, write and test rules, and produce evidence in the form your assessor expects. The skills most often missing are PCI DSS scoping, change control evidence and an independent test of the web attack prevention rules. Decide which parts you will own (for example, day-to-day operations) and which you will buy (for example, the design review or the testing). A partner's role is to plan, implement, test and document the work within the agreed scope, not to decide your compliance outcome.
Does running APISIX make our environment PCI DSS compliant?
No. APISIX can support specific controls, such as an automated technical solution for web attack prevention under Requirement 6.4.2 and strong cryptography for PAN in transit under Requirement 4.2.1, but it does not make an environment compliant on its own. PCI DSS is assessed across the whole cardholder data environment, and the entity is responsible for its scope, policies, access control, logging, vulnerability management and other requirements. Assessment is documented by a Qualified Security Assessor on a Report on Compliance or by a Self-Assessment Questionnaire with an Attestation of Compliance, and only those documents count as validation. DeployOpen prepares systems, controls and evidence, but does not issue audit reports, attestations or certifications.
Which APISIX release should we use if none is marked as LTS?
The APISIX downloads page reports APISIX 3.19.0, released on September 28, 2026, and it does not mark any release as long-term support. Choose a release based on your own support window, upgrade capacity and the security advisories you monitor, and write that policy down before go-live. Confirm with the project which versions receive fixes and for how long, and confirm the plugin behavior and TLS defaults of the version you pick, since those affect your cryptography evidence. Plan an upgrade path and test it in a non-production environment, because a version change can alter configuration evidence that your assessor has already reviewed.
Should we get a fixed-scope quote or a retainer for APISIX?
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins. A fixed-scope quote suits the initial design, build, testing and evidence package, because the boundaries are clear. Ongoing support, upgrades and continuous testing are available as retainers, which suit recurring work such as rule tuning, version upgrades and preparing evidence for each assessment cycle. Ask for the two parts to be priced separately so you can see the one-time cost and the recurring cost. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen scopes and delivers PCI-aligned gateway work
DeployOpen plans, builds and hands over Apache APISIX as a self-hosted gateway in infrastructure you control, with the web attack prevention layer, TLS configuration and evidence trail scoped in writing before work starts. We prepare the controls and records an assessor will ask for, but we do not issue validation or attestation; your QSA or the applicable reporting process makes that determination.
How we scope
- Engagements are fixed-scope, with the APISIX routes, cardholder-facing applications and environments named in writing before work starts.
- The written scope states which requirement mapping is in force, including whether the defined or customized approach is being used.
- We confirm the cardholder data environment boundary, the systems that could affect it, and which teams own each gateway route.
- The scope lists the deployment mode, the cloud, data center or air-gapped location, and the TLS and certificate sources in use.
How we build
- We deploy APISIX in your environment and configure the web attack prevention layer, then test it against your own application traffic.
- Cryptography settings for PAN in transit are configured, verified with scanning, and documented against your approved protocol and cipher list.
- Authentication, rate limits and plugin configuration are kept as version-controlled configuration, reviewed before each change is applied.
- Testing covers blocked and allowed request samples, failover behavior and rollback, with results recorded for your assessor.
How we hand over
- You receive the configuration, runbooks, architecture diagrams and a record of each test performed during the engagement.
- Log sources, retention settings and access controls for gateway logs are documented so your team can produce samples on request.
- We walk your operations and security staff through the change process, certificate renewal and incident handling for the gateway.
- Evidence is organized by requirement so your QSA can trace each control to its configuration and test record.
How we support
- Ongoing support, APISIX upgrades and continuous testing are available as retainers, scoped separately from the initial build.
- Before a PCI DSS version change or a new APISIX release is applied, we review the impact on the controls already in place.
- Retainers can include periodic rule reviews, certificate checks and re-testing after significant application changes.
- Ask any partner for the exact support hours, response commitments and upgrade terms in the written quote, as these are set per engagement.
