How open source API management supports PCI DSS for public-facing applications
A merchant, processor or service provider with internet-facing payment applications and APIs needs to know one thing first: a self-hosted gateway such as Apache APISIX can support the evidence for PCI DSS requirements 6.4, 4.2.1 and 8.6, but it does not replace the application security work or the assessment itself. The gateway can enforce some of the controls at the edge, such as web attack protection, TLS policy and authentication for API routes, while the application team still owns secure code, payment page script management and account design. PCI DSS v4.0.1 is the only active version of the standard, so the assessment should be scoped against it. The PCI Security Standards Council does not certify or approve products, so no gateway makes an environment compliant on its own. A Qualified Security Assessor or the entity's own assessment, documented on the official templates, evaluates the whole cardholder data environment, including the gateway, its identity provider, its etcd or configuration store, the hosts it runs on and the change process that governs it. Each requirement is met through the defined approach or, where the entity has robust security and risk management, the customized approach. Confirm with the assessor early which approach applies to each of 6.4, 4.2.1 and 8.6, because that choice determines what evidence the gateway must produce.
Practically, the first decisions are to confirm which public routes carry cardholder data, which of them need the 6.4.2 automated web attack protection, and where TLS terminates, so that the trusted certificate inventory required by 4.2.1.1 can be built from the gateway configuration. Ask the partner how APISIX admin credentials, route secrets and upstream credentials are stored, since requirement 8.6.2 prohibits hard-coded passwords in configuration files and 8.6.3 ties password change frequency to a targeted risk analysis under 12.3.1. Before committing to a design, ask the assessor whether they expect the gateway to be in scope as a system component, and whether any control will be handled through a customized approach that needs its own documented objective and testing.
Which PCI DSS requirements a self-hosted gateway touches and how to configure it
This table maps each PCI DSS requirement a self-hosted gateway touches to what the function must do, how to configure it in Apache APISIX or alongside Keycloak, and where the gateway alone falls short. Read it as a starting point for your assessor discussion: the gateway supplies enforcement points and logs, while the application, identity and operations controls still need their own evidence.
| Requirement | What it requires and configuration approach | What the gateway cannot cover alone |
|---|---|---|
| 6.4.1 and 6.4.2: Web attack protection | 6.4.2 (effective 31 March 2025) requires an automated technical solution that continually detects and prevents web-based attacks. Place APISIX in front of public applications with WAF-style plugins or an external WAF, route all public traffic through it, and log blocked requests. 6.4.1 is reported as not applicable once 6.4.2 applies, so confirm which vulnerability assessment evidence your assessor still expects. | The gateway filters traffic but does not fix application code. Vulnerability assessment, secure coding and rule tuning stay with your application and security teams. |
| 6.4.3: Payment page scripts | Requires an authorized script inventory, a method to confirm each script is authorized, an integrity check, and a written justification for each script. APISIX can restrict where a payment page may load scripts through response headers such as Content Security Policy managed in route configuration, and it can be kept in version control. Confirm the exact approach with your assessor and the PCI SSC guidance on payment page security. | The gateway cannot verify third-party script content or justify business need. Script inventory, integrity hashes and approval records come from the merchant's web team and tooling. |
| 4.2.1 and 4.2.1.1: Strong cryptography and trusted certificates | Requires strong cryptography for PAN over open networks, only trusted keys and certificates, validity checks, and no fallback to insecure protocol versions. In APISIX, set TLS minimum versions and cipher policy on SSL objects, manage certificates through the Admin API on port 9180 (kept off public networks), and maintain an inventory of certificates and keys. Certificate inventory under 4.2.1.1 is now mandatory. | Gateway settings do not cover backend TLS, database links or client-side behavior. Revocation checking and key lifecycle need confirmation against your certificate authority and internal PKI. |
| 4.2.2: PAN over end-user messaging | Requires PAN to be protected with strong cryptography when sent through email, chat or SMS. A gateway can block PAN patterns in request bodies routed to messaging endpoints, but the primary control is a design rule: the application should not accept or forward PAN through these channels. Document the rule and test it. | Pattern matching is not a guarantee. Messaging platforms, mail servers and staff chat tools sit outside the gateway and need their own controls. |
| 8.6.1: Interactive use of system and application accounts | Interactive use of service accounts is allowed only in exceptional, approved, time-limited cases with individual accountability. Keep gateway service identities non-interactive, expose the Admin API only to named administrators, and use Keycloak to give each operator an individual account with short-lived sessions. Record Admin API changes in version-controlled configuration. | The gateway cannot approve exceptions or prove individual accountability on shell access to hosts. Access reviews and privileged access tooling stay with the operations team. |
| 8.6.2: No hard-coded passwords | Forbids hard-coded passwords in scripts, configuration files and custom source code. In APISIX, keep upstream credentials and client secrets in a secrets backend or environment references rather than in standalone YAML files. Keep the configuration in Git, scan it for secrets before merge, and use the openid-connect plugin with client credentials held outside the repository. | The gateway cannot detect secrets already embedded in application code or CI pipelines. Secret scanning and the secrets vault are separate controls you must confirm. |
| 8.6.3: Password change frequency and complexity | Requires application and system account passwords to change at a frequency set by a targeted risk analysis under 12.3.1, and on suspected compromise. Where Keycloak holds the credentials for service or application accounts, configure password policy and rotation there, and record the risk analysis that sets the interval. Rotate gateway-held secrets on the same schedule. | The gateway does not own account passwords or the risk analysis. The interval and complexity rules must be set and evidenced by your organization, and the assessor will check the documented analysis. |
Which self-hosted platforms fit PCI DSS API controls
PCI DSS API controls usually land on three components: a gateway that sits in front of public-facing applications, an identity layer that governs how users and services authenticate, and the account and key practices around both. The options below cover the open-source gateways and identity server that most often carry this work, and the decisions that determine which one fits your traffic and cardholder data flows.
Apache APISIX as the gateway
APISIX is an Apache-2.0 gateway built on NGINX and etcd, with 3.19.0 released on September 28, 2026 and more than 100 built-in plugins covering authentication, security, traffic control and observability. It is a candidate for enforcing web attack protection, TLS policy and request controls in front of payment-related applications. Confirm that the plugins you need exist in your target version and that their behavior matches your traffic profile, since a plugin that works for general APIs may not inspect the payment flows you care about.
Kong Gateway as the alternative
Kong Gateway is also licensed under Apache-2.0, and version 3.9.4 was released on October 12, 2026. It fits teams that already run Kong for other APIs and want one policy model across estates. Compare how each gateway handles the controls you must evidence, including TLS configuration, admin access and plugin lifecycle, and confirm which features in your planned edition are open source and which depend on a commercial license before you commit.
Deployment mode and configuration control
APISIX runs in traditional, decoupled or standalone mode. Standalone mode reads a YAML or JSON file such as conf/apisix.yaml and hot-reloads changes, which suits configuration kept in Git with peer review before each change reaches production. Decoupled mode separates the data plane from the control plane over a shared etcd cluster, which suits multi-site data planes. Ask your partner which mode gives you a reviewable change history and where the Admin API is exposed.
Keycloak for identity and accounts
Keycloak is an Apache 2.0 identity and access management server that supports OpenID Connect, OAuth 2.0 and SAML 2.0, with 26.8.1 released on October 13, 2026. It addresses the account controls in requirement 8.6, including individual accountability and separation of application and system accounts, through its admin console, federation and client management. Confirm how service accounts, password rotation and credential storage will be governed, because the gateway validates tokens but does not decide which accounts should exist.
Red Hat build of Keycloak for support
The Red Hat build of Keycloak is Red Hat's supported distribution based on the open-source Keycloak project and replaces Red Hat Single Sign-On. Choose it if your assessor or internal policy expects a vendor-backed support contract for the identity layer. Confirm the supported version, the lifecycle dates and the support terms directly with Red Hat, since the version on its product page may differ from the upstream release you deploy.
Confirming plugin fit to cardholder flows
No gateway selection is complete until the plugin set is tested against the paths that carry cardholder data. Map each public-facing application and API, the points where primary account numbers enter and leave, and any third-party scripts on payment pages. Then confirm, in a test environment, which controls the gateway enforces and which must remain in the application or in a separate script management method. Record the results as evidence for the relevant requirements.
How the gateway enforces TLS, authentication and attack detection in front of applications
In traditional mode, clients reach Apache APISIX on port 9080 for application traffic, while the Admin API listens separately on port 9180. Every request therefore passes through one enforcement point before it reaches a backend. The gateway terminates TLS, applies a TLS policy that restricts protocol versions and cipher configuration, and rejects connections that fall back to insecure settings. That policy supports Requirement 4.2.1, which covers strong cryptography for cardholder data over open, public networks. It does not replace the inventory of trusted keys and certificates required by 4.2.1.1, so the team still needs to record which certificates the gateway holds, who issued them, and when each expires. Confirm with your QSA how the gateway's TLS settings and certificate records will be presented as evidence, and confirm the exact protocol and cipher settings against the current PCI SSC FAQ on TLS versions before you write them into the configuration.
Authentication for user-facing applications is delegated to the openid-connect plugin, which can work with Keycloak and use the authorization code flow with PKCE for browser and mobile clients, or the client credentials flow for service-to-service calls. The gateway validates tokens, typically through introspection or signature checks, and forwards only requests that carry an authorized token. Rate limits and centralized access logs run at the same layer, which gives the assessment a single place to show how requests were admitted and refused. Be explicit with your assessor about the boundary, though: secure coding, object-level authorization and payment page script management stay with the application and the browser. The gateway cannot confirm that a user may see a specific cardholder record, and it cannot manage the scripts a checkout page loads. Requirement 6.4.3 covers those scripts, so the payment page inventory, authorization and integrity methods need their own owner and evidence outside the gateway.
How a PCI DSS API gateway project moves from scoping to assessment
The sequence turns a gateway and identity deployment into evidence that an assessor can test against the relevant PCI DSS requirements, starting with the scope decision that everything else depends on.
Confirm scope and the cardholder data environment
Before any design work, the team agrees with the assessor and the payment brand or acquirer which systems store, process or transmit cardholder data, and which could affect its security. Each public-facing API, its upstream services, the gateway, Keycloak, the admin consoles and the CI/CD path that changes them are placed inside or outside that boundary. The team records the decision in a scope document signed off by the compliance lead. The step is complete when every gateway route that carries PAN has a named owner and a documented scope status, and the assessor has confirmed the boundary in writing.
Inventory APIs, endpoints and certificates
Engineers build a list of every public route the gateway will expose, including versions, hostnames and the services behind them, and check it against what is already running. For transport security, they add an inventory of the trusted keys and certificates that protect PAN in transit, as Requirement 4.2.1.1 now requires, with issuer, expiry, owner and renewal process for each. The inventory also shows which protocol versions and cipher configurations are accepted on each listener. The step is complete when the route list and certificate inventory reconcile with the gateway configuration and with the CMDB or certificate tool, and any gaps have tickets.
Define the approach for each requirement
For each in-scope requirement, the team chooses the defined approach, which follows the standard's stated testing steps, or the customized approach, which must show how the stated objective is met in a different way. Most gateway controls, such as web attack protection and transport security, are usually approached in the defined way, while a customized design needs a documented risk analysis and evidence that the entity has robust security and risk management. The decision for each requirement, with its rationale and the evidence it will produce, is written into a control matrix. The step is complete when the assessor has reviewed the matrix and agreed the approach for each requirement.
Deploy and harden the gateway and Keycloak
The platform team deploys Apache APISIX in the agreed mode, with the data and control plane placement set by the scope and availability decisions, and deploys Keycloak with a production database and a high availability design that needs a synchronously replicated database. Hardening covers closing the Admin API to the management network, enabling strong TLS only, disabling unused plugins and listeners, and placing a web attack protection control in front of the routes in scope. Keycloak is configured for production with the manual operator approval mode and documented upgrade windows. The step is complete when configuration is stored in version control, a hardening checklist is signed by the security engineer, and a test request confirms rejected insecure protocol and cipher attempts.
Move account and secret handling out of scripts
The team searches scripts, configuration files, pipelines and custom source code for hard-coded passwords, tokens and keys, then moves them into a secrets store. Gateway plugins and upstream connections are changed to read credentials from that store at runtime. Application and system accounts used for interactive work are reviewed against the exceptional, approved and time-limited use rules of Requirement 8.6.1, and password change rules are set from the targeted risk analysis under Requirement 12.3.1. The step is complete when a repository scan reports no hard-coded credentials and the account register shows an owner, purpose and rotation rule for each application and system account.
Build the payment page script inventory with the front-end team
Where the public application serves payment pages, the front-end team and the security team list every script that loads in the checkout or payment flow, including those from third-party tags and embedded providers. For each script they record the written justification, the method used to confirm it is authorized, and the integrity assurance method, as Requirement 6.4.3 requires. The gateway can enforce policy on what is loaded, but the inventory has to come from the application owners. The step is complete when the inventory has been reviewed against the live page, every entry has a justification and an approver, and changes to the list go through the release process.
Run testing against the in-scope routes
The team runs application and API security testing against the in-scope routes, covering the attack classes that the web attack protection rules are meant to stop, and checks that the gateway blocks them without breaking legitimate traffic. Rate limits, authentication and authorization enforcement on the gateway are tested with valid and invalid tokens. Requirement 6.4.2 calls for an automated technical solution that continually detects and prevents web-based attacks, so the team also confirms that the monitoring and alerting path works. Findings are tracked to closure with retest results. The step is complete when test reports, retest evidence and the open-findings list are filed with the control matrix.
Collect evidence for the assessor
The compliance lead assembles the evidence package for each requirement in the control matrix: configuration exports from version control, certificate and script inventories, account and secret reviews, test reports, access logs and change records from the gateway and Keycloak. Each item is labeled with the requirement it supports and the date it was produced, so the assessor can trace it without interviews. The team confirms with the assessor which format they expect and which reports the entity's assessment type requires, such as a Report on Compliance or a Self-Assessment Questionnaire with its Attestation of Compliance. DeployOpen prepares this evidence, while the assessor or the entity's own process decides conclusions. The step is complete when the assessor confirms the package covers every in-scope requirement.
Evidence assessors ask for and which component produces it
This table maps the evidence a QSA or internal assessor typically asks for under the PCI DSS requirements covered by this page to the component that produces it. Read the last column first, because it lists what the assessor still has to review, such as the scope decision, the risk analysis and the test results themselves. The main takeaway is that a gateway and Keycloak generate much of the raw evidence, but the assessed entity still owns the decisions behind it.
| Evidence item | Produced by | Assessor still reviews |
|---|---|---|
| Trusted key and certificate inventory (4.2.1.1) | Maintained as a versioned inventory, with certificate records exported from APISIX SSL objects and the Git repository that holds them | Whether every listed certificate is trusted, owned and in scope for PAN transmission |
| Certificate validity and revocation checks (4.2.1) | APISIX configuration and monitoring of expiry dates, plus the renewal process and its logs | Revocation handling in practice and whether expiry alerts reach a named owner |
| TLS configuration export (4.2.1) | APISIX SSL and route configuration exported from the Admin API or from the declarative file, showing allowed protocol versions and cipher suites | Whether the settings exclude insecure fallback and match the entity's approved cryptography baseline |
| Route and plugin change history (6.4, change control) | Git history of gateway routes, plugins and policies, with reviewed pull requests | Evidence that changes were approved, tested and tied to the change process |
| Web attack protection evidence (6.4.2) | Logs and metrics from the web application firewall or security plugins running on the gateway | Rule coverage, tuning decisions and whether blocked and bypassed events were reviewed |
| Application vulnerability test results (6.4.1 or 6.4.2 context) | Output from scanning and penetration testing of the APIs behind the gateway, stored with remediation tickets | Test scope, method, independence of the tester and whether findings were fixed |
| Keycloak client and admin account configuration (8.6) | Realm, client and role exports from Keycloak, including service account settings and admin role assignments | Whether service and system accounts are used only as approved and whether interactive use is exceptional |
| Keycloak admin and authentication audit logs (8.6.1, 10 series) | Keycloak event and admin event logs forwarded to central log storage | Log retention, review frequency and individual accountability for each admin action |
| Password policy and change records for application and system accounts (8.6.3) | Keycloak password policy settings and secrets manager rotation records | The targeted risk analysis under 12.3.1 that sets the change frequency and complexity, plus change records after suspected compromise |
| Hard-coded credential scan results (8.6.2) | Source code and configuration scanning output from the CI pipeline, with GitOps repositories scanned for secrets | Whether findings were triaged and whether scanning covers all repositories in scope |
| Payment page script inventory and justifications (6.4.3) | Not produced by the gateway; a script inventory must be built and kept by the payment page owner, with integrity monitoring output | Authorization method, integrity method and the written justification for each script |
What a self-hosted gateway alone does not satisfy
A gateway such as Apache APISIX covers part of requirement 6.4 and 4.2.1, but several PCI DSS obligations sit in the application, the payment page, the assessment process or the organization's own governance. The cards below mark where the gateway stops and what your team or partner must still produce.
No attestation or certificate from the gateway
A gateway produces configuration and logs, not validation. PCI DSS assessments are documented on PCI SSC templates: a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire, each with an Attestation of Compliance. Certificates are not recognized as validation. Ask whether your assessor accepts gateway configuration exports and logs as evidence for each in-scope requirement.
Payment page script integrity
Requirement 6.4.3 covers scripts on payment pages, which run in the browser and are outside what a server-side gateway sees. You need a method to confirm each script is authorized, a method to check its integrity, and a justified inventory of every script. Confirm which client-side controls, such as content security policy or script monitoring, your team will own.
Object-level authorization stays in the application
A gateway can require authentication and check scopes, but it does not know whether a user may read a specific account or record. Those checks, and the secure development practices behind them, remain in the application code. Ask your partner how application security testing and code review are scheduled and who signs off on findings.
Customized approach needs a documented risk analysis
If you meet a requirement through the customized approach instead of the defined approach, the evidence is your own design, risk analysis and testing, not a gateway feature. The approach is available to entities with robust security and risk management. Confirm with your assessor early whether the proposed design qualifies before building it.
Enforcement sits with the payment brands
The PCI SSC does not enforce compliance or impose penalties. Individual payment brands decide which entities must validate and run any enforcement programs. Your acquirer or brand contacts define your validation obligations, so confirm them in writing before scoping the gateway work.
Next iteration has no release date
PCI DSS v4.0.1 is the only active version, and the PCI SSC ran a request for comments on it from June to July 2026 to begin the next iteration. As of October 2026 no release date had been announced. Design the gateway configuration as code with documented mappings to requirements, so changes in a future version are easier to trace.
What buyers ask before hiring help for PCI DSS API controls
What drives the cost of PCI DSS API control work?
The cost follows the scope you give us in writing, mainly the size of the cardholder data environment (CDE), how many APIs and payment page scripts are in play, how much identity integration is needed, and how much evidence work sits on top of the technical build. Some of this is one-time: gateway design, route and plugin configuration, Keycloak integration, script inventory and the first round of testing. Some recurs: gateway upgrades, certificate and key rotation, password change cycles under 8.6.3, and periodic reviews. When you ask for a quote, request each item separately, state which costs are one-time and which are retainers, and confirm whether assessor support is included. DeployOpen does not publish a price list, and a quote follows from the written scope.
How long does a PCI DSS API controls project take?
Duration depends on the same inputs as cost: the number of in-scope applications and APIs, whether an identity provider such as Keycloak already exists, how many payment page scripts need authorization and integrity checks under 6.4.3, and how quickly your owners answer questions about traffic and certificates. Work often runs in parallel, with network and certificate inventory, gateway build, identity integration and evidence collection moving at different speeds. Your assessment calendar also sets a deadline that may be fixed before the technical work is planned. Agree a timeline in the written scope, and list the dependencies you control, such as change windows and access approvals.
What does the merchant or service provider need to provide?
The work needs named owners and accurate inventories more than it needs extra tooling. Expect to provide a list of in-scope APIs and hosts, the trusted keys and certificates used to protect PAN in transit (required by 4.2.1.1), the system and application accounts that call APIs (for 8.6), and an inventory of payment page scripts with a business justification for each (for 6.4.3). You also need an application owner who can approve routing and plugin changes, a security owner for policy decisions, and access for your Qualified Security Assessor to the configuration and logs they need. Confirm these responsibilities in the scope document before work starts.
Can our own team implement PCI DSS API controls without a partner?
A capable platform team can build a self-hosted gateway, but PCI DSS work adds requirements that many teams have not run before: documented controls that map to the standard, evidence that holds up to assessment, and change control around every gateway and identity update. The main questions are whether your team has time to own the build and the evidence, whether it can operate the gateway after go-live, and whether it understands the assessment rules for the customized approach versus the defined approach. A partner can take on the build, configuration and documentation, while your staff keep ownership of the decisions. Compare both paths against the scope, not against the tooling alone.
Does DeployOpen issue PCI DSS compliance reports or certificates?
No. DeployOpen prepares systems, configurations, documentation and evidence for your assessment, but it does not issue Reports on Compliance, Attestations of Compliance or certificates. Those come from a Qualified Security Assessor for a ROC or from your own completion of the relevant PCI SSC Self-Assessment Questionnaire and Attestation of Compliance. PCI SSC states that certificates are not recognized as validation, so do not accept a vendor certificate as proof of compliance. Ask your acquirer or payment brand which validation path applies to your organization, because the PCI SSC does not enforce compliance itself.
Is Apache APISIX or Kong better for PCI DSS work?
Neither product is certified for PCI DSS, and the choice rests on your architecture, team skills and plugin needs rather than on compliance status. Apache APISIX is licensed under Apache-2.0, supports the openid-connect plugin with Keycloak and other identity providers, and offers standalone mode driven by a YAML file, which suits Git-managed configuration. Kong Gateway is also Apache-2.0 licensed and is worth evaluating against the same requirements: TLS policy, OIDC integration, rate limits, logging and upgrade process. Test both against your own list of 4.2.1 protocol settings, 6.4 web attack controls and 8.6 account handling, then document the decision.
How do gateway upgrades affect PCI DSS evidence?
Every upgrade can change the configuration, plugins, TLS defaults or logging that your evidence describes, so each upgrade needs a change record, a retest of the affected controls and an updated inventory. Store configuration in version control so you can show what was running on a given date. Plan a rollback path and keep the release notes for the version you ran. Keycloak upgrades follow a similar pattern, and its Operator documentation recommends manual approval mode to avoid unintended updates. Ask any partner how they will keep evidence current across upgrades, and who signs off on each change.
Which PCI DSS version should our API controls target today?
Target PCI DSS v4.0.1, which is the only active version after v4.0 was retired on 31 December 2024. PCI DSS v3.2.1 was retired on 31 March 2024, so older controls mapping should be retired from your plan. The PCI SSC requested comments on v4.0.1 for a new iteration from 3 June to 20 July 2026, but as of October 2026 it has announced no release date for a new version. Confirm the version your assessor and acquirer expect, and build your evidence so that a future revision can be mapped with limited rework.
Which PCI DSS version applies and when future-dated requirements became mandatory
PCI DSS v4.0.1 is the only active version of the standard. The PCI Security Standards Council published v4.0.1 on 11 June 2024 as a limited revision of v4.0 with no added or deleted requirements. v4.0 was retired on 31 December 2024, and v3.2.1 was retired on 31 March 2024, so any assessment that still cites v3.2.1 or v4.0 is out of date. For a public-facing application or API, the practical consequence is that the controls in 6.4, 4.2.1 and 8.6 must be mapped to v4.0.1 wording and evidenced against it. Ask your acquirer or assessor to confirm in writing which version your validation uses and whether it is a Report on Compliance or a Self-Assessment Questionnaire, since the questionnaire type determines which sub-requirements appear.
Of the 64 new requirements introduced in v4.0, 51 were future-dated and became effective on 31 March 2025. Before that date they could be marked not applicable, so an assessment completed earlier may not have tested them. Requirement 6.4.2, which covers an automated technical solution for web-based attacks, superseded 6.4.1 on the same date. Check whether your last validation predates that change and whether the gap is visible in your current evidence set, such as whether a WAF or gateway-based control was in place and documented before 31 March 2025.
PCI DSS v4.x lets you meet each requirement through the defined approach or, if you have robust security and risk management, the customized approach, which meets the stated objective in a different way. A self-hosted gateway can support either path, but a customized approach needs more documented analysis of how the objective is met and how it is monitored, and your assessor must agree to it before you rely on it. Confirm with your assessor which approach they will accept for each 6.4, 4.2.1 and 8.6 control, and whether any compensating controls are still needed. The PCI SSC does not enforce compliance itself. The individual payment brands and your acquirer decide who must validate and what they expect.
How DeployOpen scopes and delivers PCI DSS API controls
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source gateways inside the client's own infrastructure. For PCI DSS API controls, we start from a written scope that ties each gateway function to the requirements it supports, then prepare the evidence an assessor will ask for.
How we scope
- Confirm which APIs and web applications sit in the cardholder data environment and which are out of scope
- Agree in writing which gateway controls cover requirement 6.4.2, 4.2.1 and 8.6, and which stay with the application team
- Map the identity provider, deployment mode and control plane location before any build work starts
How we build
- Deploy the chosen gateway, such as Apache APISIX, in your own cloud accounts or data centers with TLS policies configured
- Configure authentication plugins against your identity provider and remove hard-coded credentials from route and plugin definitions
- Keep gateway routes and plugin configuration in version control so every change has a reviewable history
How we hand over
- Test web-based attack detection and TLS settings, and document the results for your internal assessor
- Deliver an inventory of trusted keys and certificates, plus runbooks for certificate rotation and account password changes
- Train operations staff on the admin interfaces and on how evidence is produced for each in-scope control
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Roll gateway version upgrades out through a tested change process, with rollback steps documented
- Refresh evidence and configuration records ahead of your assessment window, as agreed in the retainer scope
