Which open-source tools cover PCI DSS technical requirements?
If a payment customer, acquirer or contract now expects PCI DSS validation, your team may want to use open-source tooling for the technical controls. Tools such as Wazuh, Greenbone, Keycloak, OpenBao, chrony and Coraza can produce much of the technical evidence an assessor reviews, but none of them validates compliance, and the organization owns every control, including the ones a tool supports. PCI DSS v4.0.1 is the only active version of the standard, so build your evidence against it, not against the retired v4.0 or v3.2.1.
Whether a given tool fits depends on three things: the scope of your cardholder data environment, the approach you choose for each requirement, and whether the requirement calls for a listed provider. The defined approach follows the stated test for each requirement. The customized approach, available to entities with robust security and risk management, meets the stated objective in a different way and needs its own documented evidence. Before you choose tools, confirm with your acquirer which validation type applies, then map each tool to the specific requirement it supports and the evidence it produces.
Some requirements cannot be met by a tool you run yourself. Requirement 11.3.2 requires external vulnerability scans by a PCI SSC Approved Scanning Vendor, so Greenbone can support your internal scanning work but does not replace the ASV scan. Ask your QSA which requirements they expect an independent party to perform, and confirm the license terms of each component (for example, the GPL-2.0-only and AGPL-3.0-or-later licenses listed for the tools above) with your legal team before you deploy them. The PCI SSC Approved Scanning Vendors list is the starting point for choosing that provider.
Which open-source tool maps to which PCI DSS requirement?
Each open-source tool below produces evidence for one technical area of PCI DSS v4.0.1. The tool generates logs, alerts, scan results or key operations, but the organization still owns the configuration, the policies around it and the proof that each requirement is met.
Log monitoring for Requirement 10
Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you write. Matching alerts land in alerts.log and alerts.json and in the Wazuh indexer dashboard for review. Check that every system in the cardholder data environment forwards its audit logs, that rules cover the events your assessor will ask about, and that alert review is recorded. Wazuh is licensed under GPL-2.0-only.
File integrity monitoring for 10.3.4 and 11.5.2
Wazuh file integrity monitoring records a baseline of checksums and attributes for chosen files and directories, then alerts when a user or process creates, modifies or deletes one. Scans run on a schedule or in real time and record who changed what and when. Confirm the monitored paths cover log files and payment page assets, and that alerts reach a person who responds. Wazuh is licensed under GPL-2.0-only.
Internal vulnerability scanning for 11.3
Greenbone Community Edition runs the OpenVAS Scanner, which executes vulnerability tests from the daily updated Greenbone Community Feed against target systems. Internal scans help you find and fix weaknesses between formal tests. They do not replace the external scans that must be run by an Approved Scanning Vendor under 11.3.2, so keep the two evidence trails separate. Greenbone Community Edition is licensed under AGPL-3.0-or-later.
Multi-factor authentication for Requirement 8
Keycloak supports two-factor authentication with passkeys, recovery codes and TOTP or HOTP codes from apps such as Google Authenticator or FreeOTP. One-time password policies and W3C WebAuthn settings are configurable. Confirm that MFA applies to every access path into the cardholder data environment, including administrative and remote access, and that recovery codes are controlled. Keycloak is licensed under Apache-2.0.
Key handling for Requirements 3 and 4
The OpenBao transit secrets engine encrypts and decrypts application data without storing that data, signs and verifies content, and supports versioned encryption keys with key rotation. This lets applications keep cardholder data encrypted while key material stays in a controlled service. Confirm key custody, rotation schedules, access policies and key-generation procedures are documented and tested. OpenBao is licensed under MPL-2.0.
Time synchronization for 10.6
chrony synchronizes the system clock with NTP servers or reference clocks such as GPS receivers, and it can serve NTPv4 time to other computers. Consistent timestamps are what make correlated log entries usable in an investigation. Confirm that every in-scope system points to approved time sources, that the configuration is controlled, and that drift is monitored and alerted. chrony is licensed under GPL-2.0-only.
Web attack protection for 6.4
Coraza is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It is designed to defend against attacks such as SQL injection, cross-site scripting and code injection, and it integrates with Caddy, HAProxy, Traefik and Nginx. A firewall alone does not satisfy 6.4, so confirm the rule set is tuned to your application, that blocking and alerting are tested, and that your team can show how public-facing applications are protected. Coraza is licensed under Apache-2.0.
Where an ASV is still required even with open-source scanning
Open-source scanning does not replace the external scan that Requirement 11.3.2 requires. That requirement calls for external vulnerability scans at least once every three months, performed by a PCI SSC Approved Scanning Vendor (ASV), with rescans until the passing criteria in the ASV Program Guide are met. Greenbone Community Edition, built on the OpenVAS Scanner and driven by gvmd, is well suited to frequent internal and self-directed scanning of the cardholder data environment and its adjacent networks. Its results help your team find and fix weaknesses between quarters. They do not give your assessor the ASV-issued external scan report they will ask for.
The FAQs the PCI SSC publishes on quarterly scan timing and on the four passing scans help you plan the calendar. Your external scan cycle needs to be tracked as a recurring task with an owner, a date window and a retained report. Each failing result needs a documented fix, followed by a rescan, until the scan passes. Ask your ASV which external IP addresses and domains they will scan, how they handle components that sit behind a provider such as a cloud load balancer, and how long a rescan takes to schedule. Your assessor will check the scope of that scan against your network diagrams, so the list of addresses should match the systems in scope.
Confirm the current ASV passing criteria with the ASV itself and with the ASV Program Guide before you set your remediation deadlines, because the criteria are defined there and not in this page. Ask the ASV whether an open-source scan result from your own team can be submitted as supporting evidence, and get the answer in writing. Plan your budget around the ASV engagement as a recurring cost, separate from the one-time effort of building the open-source scanning platform. Your implementation partner can configure Greenbone scan schedules and reporting, but only the ASV can run and attest to the external scan.
How the tools fit different environments
In a data center you control the physical hardware, the network segments and the change windows, so the tools are usually deployed on servers or virtual machines you already operate. The assessor will look at whether each tool sits inside the defined cardholder data environment boundary and whether its own data flows are documented. Wazuh, Greenbone, Keycloak, OpenBao, chrony and Coraza can all run in this model, but each one needs to be wired into your existing services.
- Log retention: Route Wazuh alerts and archived events to your SIEM or a protected log store, and confirm the retention period your policy sets.
- Identity provider: Connect Keycloak to your directory so that user accounts, group membership and MFA enrollment have one source of truth.
- Key custody: Decide where OpenBao unseal material and root credentials are held, and who can reach them under dual control.
- Time sources: Point chrony at internal stratum sources or approved external references, and monitor drift on every in-scope host.
- Internal ownership: Your team still owns the policies, the personnel reviews and the vendor responsibility matrix for any hardware or hosting provider.
Confirm with your QSA which network diagrams and inventories must show these tools as in scope.
When the platforms run inside your own AWS or Azure accounts, the cloud provider's PCI DSS validation covers the underlying infrastructure services, but it does not cover the open-source software you install on top of them. Those tools, their configurations and their operating system patching remain your evidence to produce. Account boundaries, network security groups and identity roles should be treated as part of the scope decision from the start.
- Log retention: Send Wazuh alerts to a centralized logging account with restricted write and delete permissions, and document how the cloud provider's logs are combined with yours.
- Identity provider: Federate Keycloak with your cloud identity or corporate directory, and restrict administrative roles to named personnel.
- Key custody: Confirm whether OpenBao runs with its own storage and auto-unseal, and whether the cloud key management service or your own HSM holds the root material.
- Scanning scope: Remember that an internal Greenbone scan does not replace the quarterly external scan performed by an ASV, which is still required for internet-facing components.
- Shared responsibility: Keep your own responsibility matrix that maps each tool to the provider's shared responsibility documentation, and ask the provider which of its reports you can rely on.
Check that no provider attestation is cited as covering a tool you installed yourself.
On an air-gapped network there is no direct internet path, so tools that normally fetch updates must receive them through a controlled transfer process. Vulnerability feeds, rule sets, container images and time references all need an approved import route, and each import is itself a change that an assessor may test. The network isolation simplifies some controls, but it makes evidence collection and time synchronization harder to get right.
- Update channel: Plan how the Greenbone Community Feed, Wazuh rule updates and package repositories reach the isolated segment, and record each transfer with its checksum and approver.
- Log retention: Keep the Wazuh indexer and archive on the isolated network, and define how exported logs leave the enclave for review.
- Identity provider: Run Keycloak locally with its own backup, and keep its administrative access on a separate management path.
- Time sources: Without internet access, chrony needs a local reference such as a GPS receiver or an internal stratum source, and drift must be monitored.
- Internal ownership: Your team still owns the policies, the personnel training and the vendor responsibility matrix for any party that handles media or transfers.
Confirm with your assessor how isolated media transfers will be documented as in-scope change activity.
How to turn tool output into assessor evidence
This sequence turns raw tool output into records a QSA can trace back to a PCI DSS requirement, a defined scope and a documented review. Each step produces an artifact the assessor can sample, from the requirement mapping through to the retained outputs and review records.
Define the requirement and the scope
Start by naming the specific requirement each tool will support, such as 10.2 for audit logging, 11.5.2 for change detection or 8.4.2 for MFA. Confirm with your QSA or the responsible internal owner which systems are in the cardholder data environment and which connected systems could affect it. The output is a short requirement-to-tool register listing each requirement, the in-scope components it covers and the named owner. The step is done when every in-scope component appears against at least one control and the owner has signed the register.
Configure the tool against the requirement
Deploy the tool inside your own environment and set it to watch the components named in the register. For example, configure Wazuh log collection and rules for the in-scope hosts, Keycloak one-time password and passkey policies for administrative access, or chrony with the approved time sources. Keep the configuration files, rule sets and policy settings in version control so changes are traceable. The output is a versioned configuration set that a reviewer can compare against the live system.
Record the baseline and configuration standards
Capture the initial state before the tool runs in production. For file integrity monitoring, this means the checksum and attribute baseline of the monitored files and directories. For the other tools, export the active policy, rule set version and scan target list. Store the baseline alongside the configuration standard that describes the approved state of each component. The output is a dated baseline record that shows what the system looked like when monitoring began, which later alerts are measured against.
Collect recurring tool outputs
Schedule the outputs that the requirement expects to see on a recurring basis. These typically include the Wazuh alert files (alerts.log and alerts.json), FIM change reports, Greenbone scan reports, Keycloak MFA policy exports and chrony source status. Confirm the scan cadence with your ASV and internal program, because external scans under 11.3.2 must be performed by an Approved Scanning Vendor rather than the open-source engine. The output is a dated set of raw files for each reporting period, stored under a predictable path.
Retain outputs in protected storage
Move the collected outputs to storage that the monitored systems and their administrators cannot alter without detection. Write them to a central location with restricted write access and access logging, and check that the retention period matches your documented policy for audit logs and related records. Verify that a sample of files can be opened and read on demand. The output is a retained evidence archive with a documented location, retention rule and access list.
Document the review and its findings
A tool that produces output without a review does not satisfy most requirements. Assign a named person to review alerts, FIM changes, scan results and MFA exceptions on the frequency your policy sets, then record what was reviewed, what was found and how each finding was resolved or accepted. Link each review entry to the specific output file it covers. The output is a review log with signed or attributable entries that a QSA can sample against the period under assessment.
Package evidence for the assessor
Before the assessment begins, assemble a package that maps each requirement in the register to its configuration standard, baseline, retained outputs and review log. Confirm with your QSA which format and sampling approach they prefer, and whether they will rely on the evidence directly or request additional detail. The package is ready when a reviewer outside the project team can follow any requirement from the register to a retained output and its review entry without asking questions. The QSA issues the report, not the tool or the implementation partner.
Licenses and what they mean for your deployment
This table compares the six open-source tools on this page by license and by what each license asks of a team that modifies or distributes the software. Read the license column first, then the obligation columns, to see which tools trigger source disclosure duties when you change them or hand them to someone else. Have counsel confirm the obligations that apply to your use before you deploy.
| Tool | License | If you modify it internally | If you distribute it or offer it to others |
|---|---|---|---|
| Wazuh | GPL-2.0-only | No duty to publish changes when used only inside your own organization | Distributed modifications must be released under GPL-2.0 with source code |
| Greenbone Community Edition (OpenVAS) | AGPL-3.0-or-later | Network users of a modified version may be owed its source, so review internal exposure | Distribution or network offering of modifications requires source under AGPL-3.0 |
| Keycloak | Apache-2.0 | No duty to publish changes | Keep license and notice files; no copyleft obligation on your own code |
| OpenBao | MPL-2.0 | Changes to MPL-covered files stay under MPL if you share them | Share source of modified MPL files; your separate files can stay proprietary |
| chrony | GPL-2.0-only | No duty to publish changes when used only inside your own organization | Distributed modifications must be released under GPL-2.0 with source code |
| Coraza | Apache-2.0 | No duty to publish changes | Keep license and notice files; no copyleft obligation on your own code |
What open-source tools cannot prove on their own
A running tool does not satisfy a PCI DSS requirement by itself. Wazuh can generate alerts, and Keycloak can enforce a second factor, but an assessor does not accept a dashboard or a configuration file as proof that a requirement is met. The organization must show that the control is defined, owned, reviewed and operating over the assessment period. Before deployment, decide which person is accountable for each tool, who reviews its output and how often, what happens when an alert is raised or a scan fails, and where the resulting records are kept. Those answers belong in written policies and procedures, and they should name roles rather than individuals who may leave.
PCI DSS v4.x gives the organization a choice in how each requirement is met. The defined approach follows the requirement as written, while the customized approach meets the stated objective in a different way and is available only to entities with robust security and risk management. The organization decides which approach it uses for each requirement, documents the decision, and the Qualified Security Assessor (QSA) tests whether that choice is valid. A customized implementation needs its own documented design, risk analysis and evidence that it achieves the objective, so it usually requires more work than the defined approach, not less. Confirm with your QSA which approach they will accept for each tool before you build around it, using the PCI SSC blog on compensating controls and the customized approach as a starting point.
Assessors test operating effectiveness over time, not a single configuration on a single day. For a log monitoring or file integrity tool, expect the QSA to ask for records showing that alerts were reviewed, that exceptions were investigated and closed, and that the tool itself kept running across the period. Plan for that history from the first day. Keep evidence of rule changes, baseline approvals, review sign-offs and any outages or gaps, and document how gaps were detected and remediated. An organization that can produce a consistent review record for three months will usually find the assessment far easier than one that configured the tools well but can show only the current settings.
Questions buyers ask about open-source PCI DSS tools
Can open-source tools make us PCI DSS compliant?
No. Open-source tools can produce technical evidence for several requirements, but compliance is a property of the whole organization and its cardholder data environment, not of any single product. The organization owns its controls, policies and processes, and an independent assessor decides whether the requirements are met. Tools such as Wazuh for log monitoring and file integrity, Keycloak for multi-factor authentication, OpenBao for key management, chrony for time synchronization and Coraza for web attack protection each cover a defined technical need. Each one still needs configuration, documented ownership and retained output that an assessor can sample. Ask any provider to show you which requirement each tool supports and which evidence it generates, and confirm the mapping with your QSA before you rely on it.
Who issues the PCI DSS report for our environment?
A Qualified Security Assessor issues the Report on Compliance for an assessed environment, or you complete a Self-Assessment Questionnaire with its Attestation of Compliance, depending on your validation type. Only the assessor or your own officer signing the attestation produces those documents. DeployOpen plans, configures and documents the self-hosted platforms and prepares the systems and evidence that the assessor reviews, but it does not issue reports, attestations or certificates. PCI SSC FAQ 1220 also makes clear that certificates are not recognized as validation, so any document claiming PCI DSS certification from a vendor should be treated with caution.
Do we still need an ASV for external vulnerability scans?
Yes, for the external scans that Requirement 11.3.2 covers. That requirement calls for external vulnerability scans at least once every three months by a PCI SSC Approved Scanning Vendor, with rescans until the passing criteria in the ASV Program Guide are met. Greenbone Community Edition, built on OpenVAS, is useful for internal scanning and for finding issues early, but its results do not replace an ASV scan for the external requirement. Confirm the current list of approved vendors on the PCI SSC site, and check with your acquirer or QSA how internal scans are evidenced for the rest of Requirement 11.
Which version of PCI DSS applies to our assessment?
PCI DSS v4.0.1 is the only active version. It was published on 11 June 2024 as a limited revision of v4.0, with no added or deleted requirements, and v4.0 was retired on 31 December 2024. v3.2.1 was retired on 31 March 2024. Many of the requirements introduced in v4.0 became effective on 31 March 2025, so an assessment performed now must meet them, not treat them as best practices. The PCI SSC opened a request for comments on v4.0.1 in mid-2026, but it has announced no release date for a new version. Your payment brands and acquirer set the timing for your validation, so confirm with them which version and deadlines apply to you.
How much effort do these tools take to run, and what drives it?
Effort depends mainly on the size and change rate of the environment, the number of log sources and monitored file paths, and how much rule tuning the team needs. Initial work covers architecture, installation, integration with your systems, baseline creation and documented procedures. Recurring work covers alert triage, rule maintenance, key rotation, scan cycles, upgrades, backups and evidence collection. Wazuh ships with more than 3,000 built-in rules and decoders, but custom rules and suppression for your own applications take ongoing attention. Ask any partner for a written estimate that separates one-time build work from recurring operations, and state which evidence will be delivered to your assessor.
Can an implementation partner set these tools up, and what does it not do?
Yes. DeployOpen plans, implements, customizes, hardens, integrates, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing support and continuous testing are available as retainers. DeployOpen does not own your controls, does not decide whether a requirement is met, and does not issue reports or attestations. Your team keeps responsibility for policies, access decisions and scope, and your QSA or ASV performs the independent assessment and scanning.
How DeployOpen deploys these tools and prepares evidence
DeployOpen plans, implements, hardens and documents self-hosted open-source tools inside your own cloud accounts, data centers or networks, mapped to the PCI DSS technical requirements they support. We prepare the systems, configurations and evidence that a QSA reviews, while your organization owns its controls and an independent QSA or ASV issues the assessment result.
How we scope
- Agree the written scope, deliverables and timeline with you before any work starts.
- Confirm which systems are in the cardholder data environment and which tools will cover each requirement.
- Identify where a PCI SSC Approved Scanning Vendor is still needed, such as external scans under 11.3.2.
How we build
- Deploy log collection, file integrity monitoring, vulnerability scanning, MFA, key management and time sync inside your environment.
- Configure rules, alert routing, baselines and access policies to match the requirements in your written scope.
- Test each control in staging, then verify alerts and failure conditions before the controls go live.
How we hand over
- Document configurations, data flows and control owners so your QSA can trace each requirement to its evidence.
- Deliver runbooks for reviewing alerts, rotating keys, rescanning and restoring from backup.
- Provide a handover session with your security and operations staff to confirm they can run the tools without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
- Review tool version updates and license changes that could affect your controls or evidence.
- Ask for a quote based on your written scope, since DeployOpen does not publish a price list.
