What EO 14028, EU CRA, and NIST CSF 2.0 Mean for Software Supply Chain Transparency

Whether you build or buy critical software, especially in healthcare, energy, automotive, or aerospace, you've likely heard of Executive Order 14028, the EU Cyber Resilience Act (CRA), and the updated National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) 2.0.

These frameworks are redefining expectations for cybersecurity across the software lifecycle, shifting the focus from source code alone to the entire software ecosystem—firmware, binaries, and connected device software included.

Here’s what each framework introduces and what it requires.

EO 14028: Software Supply Chain Security as Federal Policy

Executive Order 14028, issued in May 2021, signaled a major shift in how the U.S. federal government approaches cybersecurity, especially for software supply chains. In response to high-profile breaches like SolarWinds, EO 14028 mandates new security practices for any software sold to or deployed by U.S. federal agencies. While EO 14028 is not a direct regulation for the private sector, its downstream influence is significant: organizations in healthcare, energy, defense, finance, and others are increasingly required to align with its principles through procurement or partner obligations.

OMB Memorandum M-22-18, published in 2022, operationalizes EO 14028 by defining the criteria for what counts as “critical software” and by requiring agencies to obtain assurances from software producers regarding secure development practices.

These requirements are shaping federal procurement policy and influencing industry best practices, including how regulated sectors manage third-party software risk.

Key mandates and implementation actions:

Software Bill of Materials (SBOMs) 

Agencies must obtain SBOMs for software components that meet the criteria for critical software. These SBOMs must be machine-readable (e.g., SPDX or CycloneDX), traceable, and kept current through software updates. 

Secure software development attestation 

Software vendors must provide a signed self-attestation declaring adherence to secure development practices aligned with NIST SP 800-218, the Secure Software Development Framework (SSDF). This includes practices for source code control, build integrity, vulnerability management, and threat modeling.

Third-party software verification

Agencies are encouraged to request independent artifacts or documentation, beyond attestation, demonstrating the integrity of vendor-supplied binaries. This includes SBOMs, test results, or other evidence showing how the software was built and secured.

Inventory and vulnerability management

Agencies must maintain internal software inventories and track vulnerabilities disclosed post-deployment. Vendors are expected to support this by providing vulnerability disclosure processes and update mechanisms.

CISA SBOM guidance and tooling

The Cybersecurity and Infrastructure Security Agency (CISA) has issued guidance for SBOM generation, sharing, and validation. Tools and formats are being developed under CISA’s SBOM community efforts (including CISA’s SBOM “Minimum Elements”).

Even if your organization doesn’t sell directly to the federal government, EO 14028 and revised CISA guidance may still apply indirectly. Many organizations and integrators now require EO-aligned attestation and SBOMs as part of their supply chain due diligence. In practice, EO 14028 requirements are influencing commercial procurement standards, making transparency and secure development baseline expectations for software vendors in regulated sectors.

CISA is also in the process of updating its SBOM Minimum Elements guidance (2025 draft). We are preparing a response to their request for comments and will publish our perspective and recommendations in an upcoming blog.

NIST CSF 2.0: Third-Party and Software Supply Chain Risk 

Released in 2024, the NIST CSF 2.0 is the first major update since the framework’s original 2014 debut. It adds a sixth core function, Govern (GV), which explicitly emphasizes oversight, accountability, and third-party risk management. 

CSF 2.0 retains its flexible, voluntary structure but strengthens its guidance for software and digital supply chains. The updates align closely with federal initiatives like EO 14028, as well as emerging industry requirements in defense, healthcare, critical infrastructure, and beyond.

Key areas with direct relevance to software supply chain security:

GV.SC (Supply Chain Risk Management)
Establishes oversight of supply chain practices across procurement, legal, security, and risk teams. Emphasizes third-party transparency and accountability for software integrity and provenance.

ID.SC (Identify – Supply Chain)
Requires organizations to catalog software dependencies, vendors, and services, along with associated risk levels and operational impact. Encourages continuous updates to software inventories.

PR.DS (Protect – Data Security) and PR.IP (Protect – Information Protection Processes)
Highlights the need for secure development, controlled access to source code, hardened build systems, and lifecycle-based asset protection.

DE.CM (Detect – Continuous Monitoring)
Expands on active detection of anomalies, drift, and compromise across software and third-party components. This guidance applies directly to firmware, connected device software, and unmanaged devices, areas often excluded from traditional monitoring.

RS.CO (Respond – Coordination)
Stresses coordinated responses to supply chain incidents, including notification obligations, contract provisions, and post-incident reviews involving vendors and upstream providers.

Influence across sectors, despite its voluntary nature

Although the NIST CSF remains a voluntary framework, version 2.0 is already shaping public and private sector policy. The CMMC (Cybersecurity Maturity Model Certification), the U.S. Department of Defense’s tiered cybersecurity compliance framework for contractors, incorporates NIST CSF principles into defense contractor requirements. Agencies following EO 14028 are encouraged to map software attestation and inventory practices to CSF 2.0 functions. Regulatory bodies and insurance carriers increasingly look for CSF alignment as an indication of cyber maturity and due diligence.

The EU CRA Makes Software Security Enforceable Law

The EU Cyber Resilience Act (CRA), adopted in July 2023, shifts cybersecurity from best practice to enforceable law. Unlike previous directives, the CRA has teeth: noncompliance can result in fines of up to €15 million or 2.5% of global annual turnover, whichever is higher. Its scope is broad, extending to nearly every “product with digital elements,” including software, firmware, and connected hardware, regardless of where the product is manufactured.

Key CRA requirements include:

Mandatory SBOMs 

Organizations must provide machine-readable Software Bills of Materials for products containing software or firmware, enabling transparency across the supply chain.

Secure-by-design development 

Software must be designed with security principles embedded from the start, covering patchability, secure update mechanisms, and support across the product lifecycle. 

24-hour vulnerability reporting

Once a manufacturer becomes aware of an actively exploited vulnerability in a product, they must report it to ENISA (European Union Agency for Cybersecurity) within 24 hours.

Conformity assessments and CE marking

Products must undergo self-assessments or third-party audits, depending on their risk classification. High-risk products require external conformity checks before they can carry the CE mark and be legally sold in the EU.

What Comes Next and Why Preparation Matters Now 

The CRA enters full enforcement in 2027, but its impact is already felt. Manufacturers and software providers are actively reshaping their product development, procurement, and compliance workflows to align with CRA expectations well ahead of the deadline.

This is especially true for companies selling into Europe, integrating connected components, or relying on third-party software. Regulatory expectations are shifting fast, and procurement teams are already asking vendors how they’ll meet CRA requirements.

At A Glance: EO 14028, NIST CSF 2.0, and the EU CRA Requirements

These three frameworks differ in enforcement mechanisms and jurisdiction, but they converge on several critical expectations for software supply chain security:

Close the Visibility Gap with NetRise

NetRise provides binary-native insight into the components and risks within your software supply chain, with deep coverage for areas that are often opaque, firmware, connected device software, and legacy environments.

Our platform enables you to:

Generate SBOMs from actual deployed binaries in SPDX or CycloneDX formats, enriched with actionable metadata.

Prioritize vulnerabilities with reachability analysis, identifying which exposed functions are actually exploitable.

Track version-to-version changes with NetRise Trace, confirming what changed, what’s new, and whether binaries match expectations—even without source code.

Detect misconfigurations and policy violations with ZeroLens, surfacing embedded secrets, hardcoded credentials, and unsafe defaults other tools overlook.

Continuously monitor for new CVEs, behavioral drift, or compromise, supporting CRA post-market surveillance and CSF 2.0's continuous detection goals.

See What’s Really in Your Software

NetRise provides binary-native insight into the components and risks within your software supply chain, with deep coverage for often opaque areas such as firmware, connected device software, and legacy environments.

Want to understand what’s executing in your systems, and how to secure it?

NetRise can show you.