26.5: International Coordination and Divergence¶

Software supply chains are inherently global. A web application developed in Germany might incorporate a cryptographic library maintained in the United States, use a framework created by contributors across Asia and Europe, rely on dependencies hosted on servers in multiple countries, and serve customers on every continent. Yet the regulatory frameworks governing this borderless ecosystem remain stubbornly national, creating a patchwork of requirements that organizations must navigate simultaneously.

This tension between global software development and fragmented regulatory jurisdiction creates practical challenges for every participant in the software ecosystem. A maintainer in Brazil contributing to an open source project faces potential obligations under EU law if that software is incorporated into products sold in Europe. A U.S. software company must comply with both domestic attestation requirements and EU Cyber Resilience Act obligations. An Australian organization using software from multiple vendors confronts varying standards for supply chain security depending on where those vendors operate.

Understanding the international landscape—where approaches converge, where they diverge, and how organizations can achieve compliance across jurisdictions—has become essential for anyone building or using software in the modern economy.

Regional Approaches Compared¶

Major economies have developed distinct approaches to software supply chain security, reflecting different regulatory philosophies, legal traditions, and strategic priorities.

United States

The U.S. approach relies primarily on procurement leverage and voluntary frameworks. Executive Order 14028 establishes requirements for software sold to the federal government, using market incentives rather than direct product regulation. NIST frameworks provide implementation guidance without mandatory force. Sector-specific regulators (FDA, NERC, TSA) impose binding requirements within their domains, but no horizontal product safety regulation comparable to the EU CRA exists.

This approach preserves flexibility and industry self-regulation while creating strong incentives through federal purchasing power. However, it leaves consumer software markets largely unregulated and depends on voluntary adoption of security practices.

European Union

The EU has adopted a comprehensive product safety approach through the Cyber Resilience Act, treating insecure software as analogous to unsafe physical products. The CRA applies to virtually all products with digital elements sold in the European market, regardless of manufacturer location. CE marking requirements, conformity assessment procedures, and significant penalties create binding obligations enforced through market surveillance.

This approach provides comprehensive coverage and consistent standards but creates compliance burdens, particularly for smaller vendors and open source projects. The open source steward concept represents an attempt to balance security goals with open source ecosystem health.

United Kingdom

Post-Brexit, the UK has pursued an independent cybersecurity regulatory path while maintaining alignment with international standards. The Product Security and Telecommunications Infrastructure Act 2022 (PSTI) establishes baseline security requirements for consumer connectable products, including password requirements, vulnerability disclosure obligations, and transparency on support periods.

The PSTI's scope is narrower than the EU CRA, focusing on consumer IoT devices rather than all products with digital elements. The UK government has indicated intent to develop additional software supply chain requirements but has not yet published comprehensive legislation comparable to the CRA.

The UK's approach emphasizes principles-based regulation and industry codes of practice, reflecting a preference for flexibility over prescriptive requirements.

Australia

Australia has pursued supply chain security primarily through critical infrastructure protection and government procurement. The Security of Critical Infrastructure Act 2018, as amended, establishes cybersecurity obligations for designated critical infrastructure sectors, including requirements for supply chain risk management.

The Australian Cyber Security Centre (ACSC) provides guidance on supply chain security but without regulatory mandate for most organizations. The Hosting Certification Framework establishes requirements for cloud services hosting government data, including supply chain attestations.

Australia's approach emphasizes risk-based frameworks for critical sectors while relying on voluntary adoption elsewhere, similar to the U.S. model but with more centralized government guidance.

Japan

Japan has integrated supply chain security into its broader economic security strategy through the Economic Security Promotion Act 2022. This legislation addresses critical infrastructure resilience, supply chain security for essential goods, and security review of foreign investments.

For software specifically, Japan relies primarily on industry guidance and international standards. The Ministry of Economy, Trade and Industry (METI) has published the Cyber/Physical Security Framework (CPSF), aligned with NIST frameworks. Japan participates actively in international standardization efforts and has indicated intent to harmonize with emerging international approaches.

Comparison Summary

Harmonization Efforts and Mutual Recognition¶

Despite divergent approaches, significant harmonization efforts are underway, driven by recognition that fragmented requirements burden industry without improving security.

EU-US Dialogue

The EU-US Trade and Technology Council (TTC) has identified cybersecurity and supply chain security as priority areas for coordination. Working groups have addressed:

• Common terminology and definitions for supply chain security concepts
• Mutual recognition of conformity assessment procedures
• Alignment of SBOM requirements and formats
• Coordinated vulnerability disclosure practices

However, fundamental differences remain between the EU's product safety approach and the U.S. procurement-based model. Full mutual recognition—where compliance with one jurisdiction's requirements satisfies the other's—remains elusive. Organizations selling in both markets must currently comply with both sets of requirements, though the underlying practices (SBOMs, secure development, vulnerability management) substantially overlap.

Trans-Atlantic Data Privacy Framework

While not directly addressing supply chain security, the EU-US Data Privacy Framework demonstrates the possibility of adequacy determinations enabling cross-border operations. Similar mechanisms could theoretically apply to cybersecurity requirements, though the technical complexity of supply chain security makes this more challenging than data protection adequacy.

Quadrilateral Security Dialogue (Quad)

The Quad—comprising the United States, Australia, Japan, and India—has established cybersecurity cooperation as a strategic priority. The Quad Cybersecurity Partnership includes supply chain security elements, promoting aligned approaches among member nations.

Trade Implications¶

Supply chain security requirements increasingly intersect with international trade policy, raising concerns about disguised protectionism and technical barriers to trade.

WTO Considerations

The World Trade Organization's Technical Barriers to Trade (TBT) Agreement prohibits technical regulations that create unnecessary obstacles to trade. Security requirements must be no more trade-restrictive than necessary to fulfill legitimate objectives, must not discriminate between domestic and foreign products, and should be based on international standards where they exist.

Some observers have raised concerns that supply chain security requirements could function as non-tariff barriers, particularly when: - Requirements favor domestic suppliers or technologies - Conformity assessment procedures create delays for foreign products - Local data storage or processing requirements limit foreign vendor participation - Requirements effectively exclude products from certain countries

The EU CRA includes provisions intended to ensure WTO compliance, including recognition of international standards and equivalent third-country conformity assessment. However, trade disputes over cybersecurity requirements may increase as regulations take effect.

Market Access Challenges

For software vendors, divergent requirements create practical market access challenges:

• Products must undergo separate conformity assessment for each market
• Documentation must address each jurisdiction's specific requirements
• Timelines for market entry extend with multiple approval processes
• Smaller vendors may lack resources for multi-jurisdictional compliance

These challenges particularly affect small and medium enterprises and open source projects with limited compliance resources.

International Standards Bodies¶

International standards organizations play a crucial role in enabling harmonization by developing common technical frameworks that national regulators can reference.

ISO/IEC Joint Technical Committee 1

ISO/IEC JTC 1 develops international standards for information technology, including several directly relevant to supply chain security:

• ISO/IEC 27036: Information security for supplier relationships (four-part series addressing overview, requirements, ICT supply chain security, and cloud services)
• ISO/IEC 5230: OpenChain specification for open source license compliance (provides model for supply chain attestation)
• ISO/IEC 5962: SPDX specification for software bill of materials (SBOM format standard)
• ISO/IEC 27001: Information security management systems (increasingly includes supply chain controls)

The adoption of SPDX as an ISO standard represents a significant harmonization achievement, providing a common SBOM format that regulators can reference.

ISO/IEC JTC 1/SC 27 (Information security, cybersecurity and privacy protection) has active working groups addressing software supply chain security, including potential new standards for secure software development practices and supply chain transparency.

IEEE Standards Association

The IEEE Standards Association develops technical standards with significant supply chain security implications:

• IEEE 2883-2022: Standard for sanitizing storage (relevant to supply chain data protection)

IEEE's work on AI system trustworthiness addresses emerging supply chain concerns around model provenance and training data integrity.

OASIS and Other Consortia

Industry consortia contribute specialized standards:

• OASIS CSAF: Common Security Advisory Framework for vulnerability communication
• OASIS OpenC2: Open Command and Control for automated response
• CycloneDX: OWASP-originated SBOM format, now standardized as ECMA-424 with ISO consideration ongoing

These standards provide technical building blocks that national regulations can adopt, promoting interoperability even when regulatory frameworks differ.

Multi-Jurisdictional Compliance Strategies¶

Organizations operating across regulatory boundaries must develop strategies for efficient compliance without duplicative effort.

Establish a Unified Baseline

Rather than treating each jurisdiction's requirements separately, establish a unified security baseline meeting the most stringent applicable requirements. For most organizations, this means:

1. Implementing secure development practices aligned with NIST SSDF (satisfies U.S. attestation requirements and substantially addresses CRA essential requirements)
2. Generating SBOMs in standardized formats (SPDX or CycloneDX) meeting both NTIA minimum elements and CRA requirements
3. Operating vulnerability disclosure and response programs meeting the most demanding timelines (CRA's 24-hour initial notification with 72-hour follow-up)
4. Maintaining documentation sufficient for any jurisdiction's conformity assessment

Map Requirements Centrally

Maintain a central mapping of requirements across applicable jurisdictions, identifying: - Common requirements satisfiable by single controls - Unique requirements requiring jurisdiction-specific implementation - Conflicting requirements requiring careful navigation - Emerging requirements requiring future preparation

Update this mapping as regulations evolve, particularly during the CRA implementation period when delegated acts will specify detailed requirements.

Engage Across Jurisdictions

Participate in industry associations and regulatory consultations in each applicable jurisdiction: - Provide implementation feedback to regulators - Advocate for harmonization where requirements diverge unnecessarily - Stay informed of emerging requirements before they take effect - Build relationships with conformity assessment bodies

Consider Organizational Structure

For global organizations, consider how organizational structure affects compliance: - Establishment of EU-based entities may simplify CRA compliance - Location of development activities affects applicable requirements - Contract structures with customers should address multi-jurisdictional obligations - Insurance coverage should address regulatory risk across jurisdictions

Outlook and Recommendations¶

The international supply chain security landscape will remain fragmented for the foreseeable future. While harmonization efforts continue, fundamental differences in regulatory philosophy—product safety versus procurement leverage, prescriptive requirements versus principles-based frameworks—limit convergence potential.

Several factors may drive eventual alignment:

• Standards adoption: As international standards mature and gain regulatory recognition, de facto harmonization may occur through common technical requirements
• Industry pressure: Global software vendors will continue advocating for harmonization to reduce compliance burden
• Mutual recognition agreements: Bilateral or multilateral agreements may enable compliance with one jurisdiction's requirements to satisfy another's
• Market forces: Vendors meeting the most stringent requirements (currently EU CRA) will increasingly set de facto global standards

We recommend organizations:

1. Design for the highest common denominator, implementing practices that satisfy the most stringent applicable requirements
2. Adopt international standards (SPDX, ISO 27001, NIST SSDF) as the foundation for compliance programs
3. Monitor regulatory developments across all markets where you operate or sell
4. Participate in harmonization efforts through industry associations and standards bodies
5. Build flexibility into compliance programs to accommodate divergent requirements without complete program restructuring
6. Document compliance comprehensively, maintaining evidence suitable for any jurisdiction's assessment procedures

The global software supply chain requires global thinking about security and compliance. Organizations that build adaptable, standards-based programs will navigate regulatory fragmentation more effectively than those treating each jurisdiction as an isolated compliance exercise.