Tech Support
Documentation
Login
Contact Us
Go straight to an AI summary of this blog post instead 
Key Takeaways
- The CRA, FedRAMP, NIS 2, and PCI DSS ask the same two questions of your open source components: what you ship, and what happens when a vulnerability is found.
- They differ on the clock (PCI DSS counts from a patch’s release, FedRAMP from evaluation, and the CRA and NIS 2 set no specific time limit), on who reviews the record, and on how long you keep it (only the CRA specifies a period: at least 10 years).
- None of them says how to establish where a component came from, or who supplies the fix once its maintainers stop.
- SecureChain answers both: packages screened, rebuilt from source, patched under an SLA, and delivered with provenance, an SBOM, and VEX statements.
The Cyber Resilience Act (CRA), Federal Risk and Authorization Management Program (FedRAMP), NIS 2, and Payment Card Industry Data Security Standard (PCI DSS) each cover far more than software supply chain compliance evidence, and each asks questions that can reach the open source packages inside your product. One of those questions already has a date behind it: PCI DSS has required a third-party component inventory since March 31, 2025.
Take a hypothetical company that sells in the EU, supplies an NIS 2 entity, runs a federal cloud service, and handles cardholder data. One open source package could draw questions from a market surveillance authority, the NIS 2 customer, a federal agency, and a payment assessor. Where did it come from, and who’s patching it once its maintainers stop?
The four documents overlap in content and differ on who shows what, to whom, and for how long. The registry in the title is TuxCare’s SecureChain, which delivers open source packages through a curated repository.
Who Each Document Addresses
Each document has its own term for the party it addresses, and the terms don’t carry over. The CRA speaks to the manufacturer, which Article 3(13) defines as a person who develops or manufactures products with digital elements, or has them made, and markets them under its own name or trademark. FedRAMP’s Playbook puts primary responsibility for the security controls on the cloud service provider, and the 2026 rules say “provider.” The Playbook describes the Rev. 5 process; FedRAMP hosts it on its legacy site for reference while it moves to the 2026 rules. NIS 2 covers essential and important entities, which Articles 2 and 3 define mainly by sector and size. PCI DSS applies to entities that store, process, or transmit cardholder data or could affect its security. That includes service providers, which are entities other than payment brands that process, store, or transmit cardholder data on behalf of another entity, or provide services that could affect the security of the cardholder data environment.
| Document | Legal nature | Addressed as | Status as of October 28, 2026 | Basis |
|---|---|---|---|---|
| CRA, Regulation (EU) 2024/2847 | Regulation, binding in its entirety and directly applicable | Manufacturer (Art. 3(13)) | Applies from December 11, 2027. Article 14 applies from September 11, 2026. | Binding text |
| FedRAMP Continuous Monitoring Playbook v1.0 (November 17, 2025) and Consolidated Rules for 2026 | Program guidance (Playbook) and program rules | Cloud service provider (Playbook), provider (2026 rules) | Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) rulesets: initial and ongoing certification from December 7, 2026. Grace period ends March 7, 2027. | Guidance (Playbook). Rules marked as required. |
| NIS 2, Directive (EU) 2022/2555 | Directive, applied through each Member State’s national law | Essential and important entities (Arts. 2, 3) | Member State measures were due October 17, 2024, and apply from October 18, 2024 (Art. 41(1)). | Binding on Member States |
| PCI DSS v4.0.1 (June 2024) | Industry standard | Entities that store, process, or transmit cardholder data (Section 2) | Version 4.0.1, June 2024. Requirement 6.3.2 has been required since March 31, 2025. | Industry standard |
A company can hold more than one of these roles at once, such as manufacturer under the CRA and cloud service provider under FedRAMP, so its role determines which document’s questions apply to it. What you’d show as evidence of software supply chain compliance has a different name in each document. The CRA asks for technical documentation; FedRAMP’s Playbook requires deliverables and supporting evidence; NIS 2 requires evidence of implementation; and PCI DSS requires an assessor to examine documentation.
Note: PCI DSS v4.0.1 leaves it to the payment brands, acquirers, and other organizations that manage compliance programs to decide who must comply or validate compliance (Section 2).
What Each One Asks About Third-Party Components
What’s inside your software is referred to by a different name in each document. The CRA names open source components outright. NIS 2 talks about direct suppliers and service providers. The FedRAMP Playbook, which doesn’t mention open source or software bills of materials, covers inventory and vulnerabilities, and PCI DSS identifies third-party components within bespoke and custom software.
| Document (nature) | What it asks about components | What you show, and to whom | Retention stated | Basis |
|---|---|---|---|---|
| CRA (regulation) | Due diligence on third-party components (Art. 13(5)). Report component vulnerabilities to the maintainer and remediate them (Art. 13(6)). Identify and document components, with a software bill of materials covering at least top-level dependencies (Annex I, Part II(1)). | Technical documentation (Annex VII), kept at the disposal of market surveillance authorities (Art. 13(13)). Software bill of materials on a reasoned request from the authority (Annex VII, point 8). | Technical documentation: at least 10 years after the product is placed on the market, or the support period if longer (Art. 13(13)) | Binding text |
| FedRAMP (program guidance and rules) | Inventory at least monthly (Playbook, Section 2). Each unique vulnerability is tracked as its own plan of action and milestones (POA&M) item (Section 3). Supply chain monitoring is listed as a detection technique (VDR-CSO-DET). | Monthly POA&M and inventory to the secure repository for agency review (Playbook). Monthly vulnerability activity report to all necessary parties (VER-TFR-MHR). | None stated in the Playbook or the VER ruleset | Guidance (Playbook). Rules marked required. |
| NIS 2 (directive) | Supply chain security, including relationships with direct suppliers (Art. 21(2)(d)). Vulnerability handling and disclosure (Art. 21(2)(e)). Weigh each direct supplier’s vulnerabilities, product quality, and cybersecurity practices, including secure development procedures (Art. 21(3)). | On request, evidence of implementation of cybersecurity policies to the competent authority (Art. 32(2)(g) for essential entities, Art. 33(2)(f) for important entities). | None stated in Articles 21, 32, or 33 | Binding on Member States |
| PCI DSS v4.0.1 (industry standard) | Inventory of bespoke and custom software and its third-party components (6.3.2). Patches for critical vulnerabilities are installed within one month of release (6.3.3). Inventory of in-scope system components (12.5.1). | Documentation and interviews examined by an assessor (6.3.2.a, 6.3.2.b). | None stated in 6.3.2, 6.3.3, or 12.5.1 | Industry standard |
Note: Article 13(5) applies the due diligence duty to free and open source components even when they weren’t made available in the course of a commercial activity.
Where Software Supply Chain Compliance Evidence Overlaps and Where It Doesn’t
The overlap is in the content of the two questions. One is which components you ship. The CRA, the Playbook, and PCI DSS each ask for some form of inventory. NIS 2 lists asset management among its Article 21(2)(i) measures and asks about suppliers, and Article 21 names no component list. The other is what happens once a vulnerability is found, and all four documents address it. Under the CRA, remediation is due without delay (Annex I, Part II(2)). NIS 2 lists vulnerability handling and disclosure (Article 21(2)(e)). PCI DSS sets a 1-month-from-release deadline for patches for critical vulnerabilities (6.3.3), and FedRAMP’s 2026 rules attach the accepted vulnerability label to anything still open 192 days after evaluation (VER-TFR-MAV).
The differences start with the clocks. PCI DSS counts from a patch’s release, FedRAMP counts from evaluation, and the CRA and NIS 2 give no number in the provisions cited here. They also differ on when and to whom you show anything. A market surveillance authority has CRA technical documentation at its disposal; agencies review FedRAMP’s monthly deliverables; a competent authority can request evidence from an NIS 2 entity; and a PCI DSS assessor checks the entity’s documentation. A record built around one document’s clock and reader shouldn’t be assumed to fit another’s.
What the Documents Leave to Your Judgment
All four documents set the question and leave much of the method open. The CRA requires manufacturers to document the product’s cybersecurity aspects in a manner proportionate to the risk (Article 13(7)), and NIS 2 asks for appropriate and proportionate measures (Article 21(1)). PCI DSS leaves the timing of other applicable patches, those not for critical vulnerabilities, to the entity’s own risk assessment (6.3.3), and FedRAMP’s detection rule calls for appropriate techniques (VDR-CSO-DET).
Two questions stay open in the provisions cited so far. The first is where a component comes from. CRA Article 13(5) asks for due diligence so that third-party components don’t compromise the product, and NIS 2 Article 21(3) requires entities to weigh suppliers’ secure development procedures. Recital 85 of NIS 2, which is non-binding, describes attackers compromising entities by exploiting vulnerabilities in third-party products and services. Neither article explains how to verify that a component matches the source it claims to come from or that it contains no malicious code.
The second is where the fix comes from. PCI DSS 6.3.3 counts one month from a patch’s release, so it presumes someone has released one. The CRA places the duty to provide security updates on the manufacturer (Annex I, Part II(2)), and Article 13(8) keeps vulnerabilities in a product’s components within scope for the entire CRA support period. Under FedRAMP’s Rev. 5 continuous monitoring cycle, a finding with no upstream fix stays on the monthly POA&M as a vendor dependency. For providers with more than one agency customer, the Playbook points the monthly collaborative meeting at past-due items and vendor dependencies (Section 7). None of those provisions say where the fix itself comes from once the maintainers have stopped issuing them.
Where SecureChain for Open Source Software Fits
SecureChain from TuxCare screens the source code of open source packages for hidden malware and rebuilds them in an isolated environment from that screened code. Packages that fail inspection are blocked before they reach the customer’s environment, and the rest are delivered through a curated repository.
Each package ships with provenance (a signed record of how it was built, to SLSA Level 3), an SBOM, VEX statements, and records of origin and fix status that the documents above ask about.
SecureChain patches active components under a service-level agreement, and for versions no longer maintained upstream, Endless Lifecycle Support (ELS) backports fixes for critical, high, medium, and low-risk vulnerabilities to the versions in use, on a committed timeline. SecureChain covers open source packages in JavaScript, Python, Java, Go, and PHP.
If you can’t yet say where a component came from, or who patches it once upstream stops, see how SecureChain for Open Source Software approaches both.
FAQ
How Do the CRA, FedRAMP, NIS 2, and PCI DSS Use the Word Evidence?
All four use it, in different senses. The Cyber Resilience Act’s Annex VII lists evidence of a vulnerability-reporting contact address within technical documentation. NIS 2 Articles 32 and 33 let authorities request evidence of implementation. The Federal Risk and Authorization Management Program Playbook mentions supporting evidence, and the Payment Card Industry Data Security Standard has assessors examine documentation and interview personnel (6.3.2.a, 6.3.2.b).
How Long Must CRA Technical Documentation Be Kept?
Under the Cyber Resilience Act (CRA), Article 13(13), manufacturers are required to keep technical documentation available to market surveillance authorities for at least 10 years after placing the product on the market, or for the support period if that’s longer. Annex VII lists the contents, including a software bill of materials where applicable.
What Fines Do the CRA and NIS 2 Set?
The Cyber Resilience Act’s Article 64(2) sets fines up to EUR 15,000,000 or 2.5% of total worldwide annual turnover for the preceding financial year for breaches of Annex I and Articles 13 and 14. NIS 2 Article 34 requires Member States to set maximums of at least EUR 10,000,000 or 2% of turnover for essential entities, and EUR 7,000,000 or 1.4% of turnover for important ones. In every case, the higher amount applies.
How Does NIS 2 Reach a Software Supplier?
NIS 2 puts its duties on essential and important entities, so a supplier is usually reached through a customer. Article 21(2)(d) and Article 21(3) require the entity to weigh each direct supplier’s vulnerabilities and secure development procedures. A supplier that’s itself an essential or important entity falls under the Directive in its own right, through Member State law.
When Does PCI DSS Require a Third-Party Component Inventory?
Requirement 6.3.2 of the Payment Card Industry Data Security Standard (PCI DSS) v4.0.1, an industry standard, covers third-party components incorporated into bespoke and custom software. It was a best practice until March 31, 2025, and is required after that date. Whether an entity must validate is left to payment brands, acquirers, and other organizations that run compliance programs.
