What does the EU Cyber Resilience Act mean for PostgreSQL and its community?

October 2026

peter@eisentraut.org
https://peter.eisentraut.org/
@petereisentraut@mastodon.social

peter.eisentraut@enterprisedb.com
https://www.enterprisedb.com/
@edbpostgres@mastodon.social

• medical devices
• motor vehicles
• civil aviation products
• marine equipment
• spare parts
• products exclusively for defence purposes
• products specifically for processing classified information

• trade fairs, exhibitions, demonstrations (with marking)
• unfinished software for testing purposes (with marking)

• important, e.g.:

  • browsers
  • password managers
  • operating systems
  • network management systems

• critical, e.g.:

  • hypervisors
  • firewalls

⇒ does not affect PostgreSQL

• entered into force on 10 December 2024
• applies from 11 December 2027
• reporting obligations of manufacturers (Art. 14) from 11 September 2026
• notification of conformity assessment bodies (Chap. IV) from 11 June 2026

• in each member state:
  • market surveillance authority (🔗list)
  • CSIRT designated as coordinator (🔗list)
  • notifying authority (🔗list)
• ENISA 🇪🇺

• Cyber Resilience Act (CRA) (Regulation (EU) 2024/2847): government regulation of PDE placed on the market
• Product Liability Directive (PLD) update (Directive (EU) 2024/2853): extends/clarifies product liability to software
• 2nd Network and Information Security directive (NIS2) (Directive (EU) 2022/2555): cybersecurity for (critical) infrastructure
• Digital Operational Resilience Act (DORA) (Regulation (EU) 2022/2554): cybersecurity for financial sector

a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge

a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products

(Source: Commission guidance on the application of the Cyber Resilience Act (CRA))

company that sells PostgreSQL or variants with support	manufacturer
company that sells (only) training or consulting for PostgreSQL	neither
company that sells PostgreSQL DBaaS	neither
company that does not sell any services around PostgreSQL but develops an open source software for internal use and also offers it for download	steward
Cloud Native Computing Foundation → Linux Foundation	steward
PostgreSQL Europe association	steward (?!?)
Software in the Public Interest (SPI)	steward
PostgreSQL Core Team	neither
PostgreSQL Security Team	neither
individual PostgreSQL hacker	neither

(excerpt; CRA Art. 13)

• product complies with essential cybersecurity requirements
• risk assessment (kept up to date)
• due diligence when integrating components sourced from third parties
• report vulnerabilities in integrated components to manufacturers or maintainers, share modifications
• vulnerabilities are handled
• at least 5 years of security support
• (can be limited to latest version, if upgrades are easy)
• security updates available for at least 10 years
• single point of contact for reporting vulnerabilities
• conformity assessment and declaration
• technical documentation

(excerpt; CRA Annex I Part I)

• made available on the market without known exploitable vulnerabilities
• made available on the market with a secure by default configuration
• ensure protection from unauthorised access by appropriate control mechanisms
• protect the confidentiality of stored … data
• resilience and mitigation measures against denial-of-service attacks
• provide security related information by recording … activity

⇒ harmonised standards

(excerpt; CRA Annex I Part II)

• drawing up a software bill of materials (SBOM) in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products
• where technically feasible, new security updates shall be provided separately from functionality updates
• apply effective and regular tests and reviews of the security of the product with digital elements
• put in place and enforce a policy on coordinated vulnerability disclosure

• either self-assessment or assessment by certified body

• include conformity declaration (or on website)

• affix CE marking

(excerpt; CRA Art. 14)

• report actively exploited vulnerabilities
• report severe security incidents
• inform the impacted users

(24h)

from 11 September 2026!

⇒ single reporting platform (SRP) (🔗link)

(CRA Art. 15)

• everyone can report vulnerabilities, “cyber threats” or security incidents to CSIRT or ENISA
• manufacturers are informed
• no additional obligations upon reporter

(CRA Art. 24)

• put in place “cybersecurity policy”
• cooperate with the market surveillance authorities
• reporting obligations like manufacturers (Art. 14)
  • if involved in the development
  • if providing infrastructure
• no administrative fines against open-source software stewards (Art. 64(10))

In order to facilitate the due diligence obligation set out in Article 13(5), in particular as regards manufacturers that integrate free and open-source software components in their products with digital elements, the Commission is empowered to adopt delegated acts in accordance with Article 61 to supplement this Regulation by establishing voluntary security attestation programmes allowing the developers or users of products with digital elements qualifying as free and open-source software as well as other third parties to assess the conformity of such products with all or certain essential cybersecurity requirements or other obligations laid down in this Regulation.

to support due diligence and work toward attestations

• Authorship: clearly identify maintainers
• Governance: documentation, contribution guideline
• Licensing: license clearly identified; open-source license for all components, artifacts, and all dependencies
• Quality: identify third-party dependencies, public source code and change history, vulnerability reporting guide, repeatable testing procedures, memory safety mitigations, more than one contributor, change review required
• Build and Release: build instructions, version numbering, secure asset distribution, release notes
• Vulnerability Management: identify security contact, timely handling of vulnerabilities
• End-of-Life: clearly communicate discontinuation of support

based on

• https://github.com/orcwg/cra-attestations/blob/main/proposals/template-lite.md
• OpenSSF CRA Readiness Guide for Maintainers and Developers

• EU
  • Cyber Resilience Act (EUR-Lex)
  • Cyber Resilience Act - Implementation (EU)
  • Commission guidance on the application of the Cyber Resilience Act (CRA)
• member states' MSAs and CSIRTs
  • (see lists earlier)
• information for open source work
  • OpenSSF
  • ORC WG
• training courses
  • Eclipse Foundation
  • Linux Foundation

peter@eisentraut.org
https://peter.eisentraut.org/
@petereisentraut@mastodon.social

peter.eisentraut@enterprisedb.com
https://www.enterprisedb.com/
@edbpostgres@mastodon.social