Navigating 2026 Secure SDLC Regulations

In January 2026 the United States made secure software development attestation optional. In September 2026 the European Union starts requiring vulnerability reports within 24 hours. Same year, opposite directions.

That divergence is the single most useful thing to understand about secure SDLC regulation this year. The paperwork regime that dominated 2022 through 2024 has been dismantled in Washington and rebuilt, with hard dates and civil liability attached, in Brussels. If you sell software into both markets, your binding constraint moved.

The United States replaced a mandate with a risk decision

OMB Memorandum M-26-05, signed 23 January 2026, rescinded M-22-18 and M-23-16. The government-wide requirement for software producers to attest to secure development practices is gone. Agencies may now use the CISA Secure Software Development Attestation Form based on their own risk assessment, and they may ask for an SBOM on request. NIST SP 800-218 (the SSDF) is described as an available resource rather than a mandate. The memo sets no agency deadlines. Its stated reasoning is that the prior regime "imposed unproven and burdensome software accounting processes that prioritized compliance over genuine security investments."

The practical effect is fragmentation. Attestation obligations now live in individual contract clauses rather than in one government-wide policy, and CISA's attestation form page still carries no 2026 status notice, so the published guidance and the operative policy currently disagree.

Three other US threads matter:

The SSDF is being revised, not retired. EO 14306 (6 June 2025) struck the machine-readable attestation and DOJ-referral machinery out of EO 14144, and directed NIST to update the SSDF. The initial public draft of SP 800-218r1 (SSDF 1.2) landed 17 December 2025 and closed for comment on 30 January 2026. It adds two practices: PO.6 (a continuous process improvement plan) and PS.4 (ensure software updates are robust and reliable). The final version had not been published as of 11 August 2026.

Federal acquisition is consolidating. The Revolutionary FAR Overhaul Phase 2 proposed rule, published 23 June 2026, folds security provisions from FAR Parts 4, 25 and 40 into a restructured FAR Part 40, requires contractor systems handling CUI to meet NIST SP 800-171 Revision 3, and sets 72 hours for CUI incident reporting, relaxed from the 8 hours proposed in January 2025. Separately, the Department of War suspended CMMC Phase 2 on 13 July 2026, while DFARS 252.204-7012 obligations continue.

SBOM went international and stayed voluntary. The 2026 Minimum Elements for a Software Bill of Materials, published 29 July 2026, carries the seals of CISA, NSA, FBI and 15 international agencies including BSI, ANSSI, METI, KISA, CERT-In and ACSC. It defines 17 required fields, and the new ones are the interesting part: SBOM author signature, hash algorithm and hash value, component license, generation context, and tool name and version. VEX is discussed as complementary, not required. Nothing in it is mandatory anywhere. The convergence is on format, not obligation, and the added signature and hash fields signal that the next argument will be about whether an SBOM can be trusted, not whether it exists.

The European Union set hard dates and attached liability

The Cyber Resilience Act, Regulation (EU) 2024/2847, is the one with a clock running. From 11 September 2026, Article 14 reporting applies to manufacturers of products with digital elements:

• An actively exploited vulnerability triggers an early warning to the relevant Member State CSIRT and simultaneously to ENISA within 24 hours, a vulnerability notification with detailed assessment within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available.
• A severe incident affecting product security triggers an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month.
• Affected users must be informed of the vulnerability or incident and the available corrective measures without undue delay.
• If the vulnerability sits in an integrated third-party component, including open source, the manufacturer or maintainer of that component must be notified.

Submissions route through the ENISA Single Reporting Platform. Full application of the CRA, including the essential cybersecurity requirements, conformity assessment and CE marking, follows on 11 December 2027.

The Commission published final interpretative guidance on 27 July 2026 (C(2026) 5252 plus annex), with 67 worked examples covering remote data processing, free and open source software, substantial modification and support periods. It is non-binding but it is the clearest read available on scope.

The real 2026 risk in the CRA is not the reporting date. It is the standards gap. Standardisation request M/606 covers roughly 41 standards, and a draft Commission amendment published 30 July 2026 pushed the deadlines back two months: the first core horizontal standards, covering secure development and vulnerability handling, are now due 30 August 2026, with vertical product-specific standards due 30 October 2026. None of the core horizontal secure-development standards were confirmed published as of 11 August 2026, which leaves roughly fifteen months to full application with no presumption of conformity to build against.

NIS2 already requires what the CRA is formalising. Article 21(2)(d) covers supply chain security and 21(2)(e) covers security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure. Transposition remains incomplete: the Commission has referred Ireland, Spain, France and the Netherlands to the Court of Justice for failing to notify transposition measures. A targeted amendment proposal from 20 January 2026 would add a small mid-cap category and simplify jurisdictional rules, alongside a proposed revision of the Cybersecurity Act. Both are proposals, not law.

DORA has applied since 17 January 2025. Its RTS on the ICT risk management framework requires secure development lifecycle controls including source code testing, secure coding, environment separation and change management, and the threat-led penetration testing delegated regulation was adopted 13 February 2025 with scope explicitly reaching systems hosted by critical third parties.

The revised Product Liability Directive is the enforcement layer nobody is planning for. Directive (EU) 2024/2853 must be transposed by 9 December 2026 and applies to products placed on the market after that date. Software is expressly a product. Defectiveness assessment accounts for the product's ability to learn or change after release, the products it interacts with, and relevant cybersecurity requirements. Where a manufacturer retains control through updates, liability can attach to failure to supply security updates. There are procedural disclosure obligations and rebuttable presumptions of defect and causation where technical complexity makes proof excessively difficult. As of mid-2026 only Hungary had fully transposed. This is the first time an SDLC failure that leaves an exploitable defect can produce uncapped EU civil liability for personal injury, property damage and data loss.

Asia Pacific regulates the product, not the development process

The pattern across the region is certification, grading and product obligations rather than documented development practice.

China amended its Cybersecurity Law for the first time in a decade, effective 1 January 2026. Penalties rose sharply, up to RMB 2 million to 10 million for particularly serious cases, with new penalties for selling uncertified critical network equipment and dedicated cybersecurity products, and explicit extraterritorial liability including potential asset freezes. The Regulations on Network Data Security Management have applied since 1 January 2025. There is no PRC analogue to the SSDF or CRA Article 13 requiring documented secure development. The binding constraints are product certification, MLPS grading and data localisation, which shape architecture more than process.

Japan enacted its Active Cyberdefense legislation on 16 May 2025, with phased implementation running to 2027. The provision that matters for software vendors: IT vendors must address government notifications about vulnerabilities and make reasonable efforts to respond to ministerial requests on corrective action. METI, with Japan's National Cybersecurity Office, co-signed the 2026 SBOM minimum elements on 30 July 2026.

Australia produced the region's one genuinely new binding product-security obligation. The Cyber Security (Security Standards for Smart Devices) Rules 2025 commenced 4 March 2026 for relevant connectable consumer products manufactured on or after that date. Three requirements: no universal default passwords, a published means to report vulnerabilities with status updates, and disclosure of the support period including a defined end date for security updates. Suppliers must provide a statement of compliance.

Singapore brought the Cybersecurity (Amendment) Act provisions into force on 31 October 2025, extending coverage beyond critical information infrastructure. The Safe App Standard 2.0 remains voluntary. A CCoP 2026 update was announced 22 July 2026 for launch later in the year, adding board-level accountability and Cyber Trust Mark Level 5 certification for CIIs, with a cloud-specific code planned for the second half of 2026.

India notified the DPDP Rules 2025 on 14 November 2025 with an eighteen-month phased compliance period, mandating reasonable security safeguards with penalties up to 250 crore rupees, and CERT-In co-signed the 2026 SBOM minimum elements.

South Korea co-signed the same SBOM guidance through KISA. Claims that Korea has mandated SBOMs circulate widely in vendor content and are not supported by any statute, decree or MSIT notice we could locate. Treat Korean secure-development obligations as an open question rather than a settled requirement.

The 2026 calendar, in one place

Every 2026 obligation asks a question a document cannot answer

Read the new rules next to each other and the pattern is hard to miss. They stopped asking how you build software and started asking what your software actually contains and does.

A CRA 24 hour clock starts when a vulnerability is actively exploited. That is a statement about a running system, not a scanner queue. The final report is due 14 days after a corrective or mitigating measure is available, which requires knowing whether the fix reached the deployed artifact. Article 14 requires notifying the maintainer of an affected integrated third-party component, which requires knowing which transitive dependency is actually present in what shipped, the job of runtime-powered SCA rather than a manifest read. The 2026 SBOM minimum elements ask for hashes and a signature, which means the inventory has to match the built artifact. The Product Liability Directive attaches liability to failing to supply security updates during the period of manufacturer control, which is a question about deployed versions.

Documentation cannot answer any of those. Reachability analysis narrows the field, and static reachability is a genuine improvement over severity sorting. But reachability analysis describes what is possible in code. The regulations ask what is real in production.

That gap is where runtime intelligence does the work. Reading the running process tells you which packages loaded, which vulnerable functions were invoked, which components are present at runtime but absent from the manifest, and whether a deployed environment still contains the version you thought you fixed. Those are the exact inputs the 2026 rules require, produced as evidence rather than assertion.

Mapping Kodem capabilities to the 2026 requirements

The table below maps specific obligations to the capability that produces the evidence. Every row carries its capability status, so anything that is not generally available is visible as such, and rows whose citation still needs a second check are marked in place. The complete matrix runs to sixteen columns including prerequisites, source verification and per-row notes, and is published as a downloadable workbook alongside this post.

Fourteen clauses are shown here. The full matrix covers 30 mapped obligations with sixteen columns, including prerequisites, capability detail, source verification and per-row notes.

The through-line is that each row produces an artifact with provenance rather than a claim. When a regulator, an auditor or a customer asks how you know, the answer points at observed execution. The same evidence that shortens a reporting clock is the evidence that makes vulnerability management tractable the rest of the year, and the remediation side of the loop runs through Kai's remediation agent rather than a spreadsheet of tickets.

What to do in the next ninety days

Four things, in order of how much they will hurt if you skip them.

Confirm whether the CRA applies to you and who files. If you place products with digital elements on the EU market, the 11 September 2026 clock is yours, and the reporting duty sits with the manufacturer even when the vulnerability sits in an upstream component. Register for the ENISA Single Reporting Platform and rehearse a 24 hour notification before you need one.

Build the component-to-artifact link now, not in 2027. The CRA's essential requirements, the 2026 SBOM fields and the Product Liability Directive all assume you can tie a component to a shipped, deployed artifact. That plumbing takes longer than the reporting workflow.

Do not treat the US rescission as a reduction in work. Attestation moved from a policy mandate into contract clauses, and in-flight clauses were not addressed by M-26-05. Read your contracts.

Assume the harmonised standards will land late. Compressed adoption is the likely outcome for the CRA's horizontal secure-development standards. Teams that already collect execution evidence will map to whatever the standard says. Teams that plan to start when the standard publishes will not have time. Most of the groundwork is the same work as securing the SDLC properly, which is a useful thing to notice when you are asking for budget.

The 2022 to 2024 wave of software security regulation asked for a description of your process. The 2026 wave asks for the state of your product. That is a harder question, and it is a better one, because the answer is either observable or it is not. Compliance is becoming an evidence pipeline. The teams that will pass in 2027 are the ones building it in 2026.