WordPress Security Compliance & Regulations  ## Metadata - Author: [[Oliver Sild]] - Full Title: WordPress Security Compliance & Regulations - Category: #articles - Document Note: --- tags: - #wordpress - #security - #compliance - #regulations - #pcidss - #gdpr - #cyberresilience - #opensource - #plugins - #mfa Author: Oliver Sild Source: Personal website (Article) Reference: https://oliversild.com/wordpress-security-compliance-regulations/ date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} --- # Title: WordPress Security Compliance & Regulations ## Table of Contents: - [🔎 Overview](#-overview) - [💳 PCI DSS v4: What Changed and Why It Matters](#-pci-dss-v4-what-changed-and-why-it-matters) - [🧩 Key Requirements to Watch (6.3 and MFA)](#-key-requirements-to-watch-63-and-mfa) - [🏛️ EU Cyber Resilience Act (CRA)](#-eu-cyber-resilience-act-cra) - [🌍 Ecosystem Response & Implications](#-ecosystem-response--implications) - [📌 Recommendations & Next Steps](#-recommendations--next-steps) - [📖 References](#-references) ### References: - PCI DSS v4 summary and interpretation - EU Cyber Resilience Act overview and legislative updates - GDPR as precedent for mainstreaming compliance in WordPress - Open source CMS joint letter regarding CRA (WordPress, Drupal, Joomla!, TYPO3) Note: The article itself references these; official source documents should be consulted for final implementation details. ## 📝 Summary: The article argues that security compliance and regulation will become central to WordPress in the near future. GDPR made privacy practices mainstream; now PCI DSS v4 (effective March 31, 2024) and the EU Cyber Resilience Act (CRA) will impose more stringent security obligations on merchants, site owners, and software publishers—including WordPress plugin and theme developers. Key shifts include mandatory vulnerability management for payment pages (Requirement 6.3), broad multi-factor authentication (MFA) expectations, and CRA obligations for software manufacturers to conduct regular audits, adopt coordinated vulnerability disclosure, and face significant penalties for non-compliance. ## 📖 Main Content: The piece frames a regulatory wave moving from privacy (GDPR) to security (PCI DSS v4, CRA). For WordPress: - PCI DSS v4 removes the “third-party processor” escape hatch—merchants must still secure “payment pages,” not just offload risk. The standard adds 50+ new requirements, highlighting vulnerability identification/mitigation and more universal MFA. - CRA shifts obligations to software manufacturers with EU reach, which, in practice, includes most WordPress plugin/theme authors. It requires proactive security practices (audits, code reviews) and mandatory coordinated vulnerability disclosure, ending silent security patches. Non-compliance can carry substantial fines. Together these instruments professionalize security expectations in the WordPress ecosystem, changing developer and merchant responsibilities and catalyzing better security hygiene. ### 🗒️ Notes - Context - “Security compliance and regulations are topics that are not often discussed” in WordPress but will grow in importance. - GDPR set the precedent for compliance becoming mainstream. - PCI DSS v4 (effective Mar 31, 2024) - 50+ new requirements for any site accepting card payments (including WooCommerce). - Third-party processors no longer exempt merchants from securing their own payment pages. - Requirement 6.3: Security vulnerabilities must be identified and addressed. - Ongoing view of vulnerabilities; protective measures required. - MFA requirement: - Enforced MFA, especially where payment data is handled, stored, or surfaced back to users. - Author notes v4 is “quite clear” that 2FA/MFA should be broadly deployed. - EU Cyber Resilience Act (CRA) - Regulates how security is managed for software products accessible in the EU. - Obligations fall on software manufacturers/publishers—applies globally if EU users are present. - Implications for WordPress plugin/theme developers: - Regular security audits and code reviews. - Coordinated vulnerability disclosure (no hidden security fixes). - Enforcement expected in 2024; significant penalties for non-compliance (up to the higher of €15M or 2.5% global turnover). - Ecosystem action - WordPress, Drupal, Joomla!, TYPO3 issued a joint letter of concern to the EU regarding CRA. - Takeaway - New regulations are inevitable; start aligning development and operations with these standards now. ## 📖 References: - PCI DSS v4 (Payment Card Industry Data Security Standard) effective 2024-03-31 - EU Cyber Resilience Act (European Parliament approved standards; 2024 enforcement expected) - GDPR as historical precedent - CMS joint advocacy regarding CRA ## 🗣️ Paraphrase: 1) Original idea: PCI DSS v4 ends the notion that using a third-party payment processor negates merchant obligations to secure payment pages. It introduces over 50 new requirements, with special emphasis on vulnerability management and MFA. Paraphrase: The updated PCI rules remove the loophole where merchants could rely solely on processors for compliance. Even if Stripe or similar handles the transaction, your site’s payment pages must be secured. With dozens of new requirements, the standard elevates continuous vulnerability oversight and multi-factor authentication to baseline expectations. 2) Original idea: CRA imposes security obligations on software manufacturers who publish code available in the EU, including open source, requiring audits, code reviews, and coordinated disclosure—with hefty fines for non-compliance. Paraphrase: The CRA places responsibility on anyone distributing software accessible to EU users, regardless of where they’re based or whether their code is open source. Developers will be expected to regularly assess and improve security, adopt transparent vulnerability disclosure processes, and face substantial penalties if they fall short. ## 📰 Newsletter: WordPress world, buckle up: compliance just got real. GDPR brought privacy center stage—now PCI DSS v4 and the EU Cyber Resilience Act are making security everyone’s day job. If you run WooCommerce or accept cards anywhere, PCI v4 (in effect since March 31, 2024) means you can’t hide behind third-party processors—your payment pages must be secured. Expect ongoing vulnerability management and MFA across the board. On the dev side, the CRA treats plugin/theme authors like software manufacturers, requiring regular security audits, code reviews, and coordinated vulnerability disclosure—no more stealth fixes. Non-compliance could be costly. Learning web development? This is your moment to master secure coding, dependency hygiene, and MFA integration. Community highlights: cross-CMS collaboration continues as WordPress, Drupal, Joomla!, and TYPO3 advocate for practical CRA implementation. New plugins worth exploring: security scanners with SBOM support, login security/MFA suites, and auto-patching utilities. Pro tip: map your store’s data flows and implement coordinated disclosure guidelines in your repos. Helpful reads: PCI DSS v4 implementation guides and CRA overviews from EU sources. Got a favorite MFA plugin or disclosure policy template? Share it with us and we’ll feature the best community picks next issue. ## ✅ Action Items: Prompt tailored to your role (Developer Advocate at GoDaddy, OSPO-aspiring, educator, and open source community builder): - Alignment to open-source advocacy: - Map how CRA obligations translate to WordPress plugin/theme maintainers: audits, code reviews, SBOMs, and coordinated vulnerability disclosure. Create workshops and policy templates for maintainers. - Contributor engagement: - Develop contributor guides on secure coding standards aligned with PCI v4/CRA. Introduce “security triage” contributor roles in community sprints. - Education: - Build curricula covering PCI v4 payment page hardening, MFA implementation patterns, and vulnerability management workflows. Include hands-on labs for WooCommerce and headless setups. - OSPO trajectory: - Propose organization-wide policies: coordinated disclosure, severity matrices, patch SLAs, SBOM generation, and third-party dependency risk management. - Transparency & inclusivity: - Publish public security roadmaps and disclosure practices. Offer mult - Summary: Security compliance and regulations are topics that are not often discussed in the context of WordPress, but this is going to change significantly in the coming years. - URL: https://oliversild.com/wordpress-security-compliance-regulations/  Security compliance and regulations are topics that are not often discussed in the context of WordPress, but this is going to change significantly in the coming years. GDPR was one of the first regulations to make some compliance practices mainstream in the WordPress ecosystem. At the end March 2024, PCI DSS v3 retired and was replaced by PCI DSS v4, which introduced significant changes to compliance for everyone who accepts credit card payments on their website (regardless of whether the processing is done via a third-party provider). Then there’s also the upcoming European Cyber Resilience Act, which brings significant regulatory security requirements to the open-source software ecosystem. This is so significant that WordPress, Drupal, Joomla!, and TYPO3 joined forces to send a letter of concern to the European Union. Whether we want it or not, new regulations are coming. #### **The New PCI DSS Version 4** The first one to take effect is PCI DSS version 4 (31st March 2024), which introduces more than 50 new requirements for vendors (such as WooCommerce sites) who process payment data. One of the most significant changes is that merchants can no longer bypass PCI requirements just because they use a third party to process payments for them. The new PCI DSS v4 specifically states that merchants need to protect the payment pages. As mentioned, there are 50 new requirements that come with the new PCI compliance, but I would like to highlight two of them, which will probably create a significant shift in the market. **Requirement 6.3:** Security vulnerabilities are identified and addressed. Vulnerability management is no longer an option. Every website that has payment pages where a customer can enter credit card information must have an ongoing overview of security vulnerabilities present in the application, and the application needs to be protected. **Multi-Factor Authentication (MFA) Requirement** Websites that handle payment information, store it, and show it back to the user must enforce multi-factor authentication. The new PCI DSS v4 is quite clear about the fact that **2FA/MFA should essentially be deployed for everyone.** There’s a lot to unpack when it comes to PCI, but I recommend everyone who accepts credit card payments on their website or shop to look into this. #### **EU Cyber Resilience Act** The European Cyber Resilience Act essentially regulates how security should be managed for software products. The CRA puts its obligations on software manufacturers, those who publish code that is available in the EU. This actually covers anyone who publishes software on the Internet, open source or not, regardless of whether you’re in the EU or not – as you would likely have EU users. This will directly affect all WordPress plugin developers, for example, who will be required to perform regular security audits and code reviews on what they produce, and they will need to enforce a coordinated vulnerability disclosure policy (no more hidden security fixes). The European Parliament already approved the new cyber resilience act standards, so it’s expected to become enforced already somewhere in 2024. Every plugin/theme developer in the WordPress ecosystem should already start looking into the requirements today. As with most recent European technology regulation, non-compliance could result in significant fines: up to the higher of €15 million or 2.5% of global turnover. Just like with PCI, there’s also a lot to unpack with the CRA. I’ll add resources for that as well. **Resources:**, WordPress Security Compliance & Regulations, Oliver Sild, 01k36n20xw2p88rtzzhdx4gza5.