Voluntary Meets Mandatory: How Three Rulebooks Quietly Converge on One Story

Put three documents on a table: a decades-old functional safety standard; a yet-to-be published technical specification about artificial intelligence; and a piece of European cybersecurity law with a stopwatch built into it. They come from different institutions, serve different masters, and ostensibly speak different dialects. You would not necessarily expect them in the same conversation.

But read them together anyway, and you come away realizing that they are all describing the same shift from three different entry points, and once you see it you cannot unsee it: safety and security, disciplines that spent decades in separate domains, are being merged into the same one.

The old division of labor

For a long time you could keep these worlds apart, and sensibly so. Functional safety asked a central question: will this system fail in a way that hurts someone? Security asked a different one: can someone make this system do something it was never meant to do? One rests on identifying the risk of an accident. The other focused on bad actors or adversaries. When safety-critical systems were isolated and predictable, that separation held.

The foundational functional safety standard, IEC 61508, still carries the fingerprints of that era. In its own text it sets security aside, stating plainly that it does not cover protection against unauthorized persons affecting functional safety, nor the security policies such protection would require.¹ That is not an oversight. It is a snapshot of a world where the threat was perceived as failure, not intrusion.

What closed the gap

Connectivity closed the gap. The moment safety systems became networked, software-driven, and remotely updatable, a security failure became a safety failure. Compromise the system and you can defeat the very functionality meant to keep people safe. Security stopped being safety's neighbor and became its precondition. Here is the interesting part: standards, specifications, and regulations are now registering that change, each in its own idiom.

Entrypoint number one: the safety standard is being rewritten. IEC 61508 is undergoing its first major revision in years, and the in-progress 2025 edition is reported to pull cybersecurity and human factors into scope, the very things the current version does not address.² That is worth a reread. The foundational functional safety standard is being rewritten to include the thing it once excluded. When a standard reverses its own boundary, it is telling you the ground moved.

Entrypoint number two: the AI specification fuses safety and security from the start. The emerging ISO/IEC TS 22440 addresses functional safety for AI systems, and it exists because the old assumptions are no longer the case. Traditional safety standards presumed systems behave deterministically and fail in understood ways; AI does neither.³ Note where security sits in this work. It is not a separate chapter. The specification's own material treats how security threats can affect the safety of an AI system as part of the problem, not adjacent to it.⁴ AI is where safety and security stop being separable even in principle. It is worth noting, however, that this technical specification is still in development, and is currently taking shape rather than being a settled rulebook at the moment.⁵

Entrypoint three: the law arrives, and it arrives first. The EU Cyber Resilience Act is pure security regulation. It never mentions functional safety. But it governs “products with digital elements,” which is precisely the category that connected safety-critical products fall into, and it carries a clock: report an actively exploited vulnerability within 24 hours, a fuller notification within 72, a final report within 14 days of a fix.⁶ The detail that should catch everyone's eye is the timing. Article 14's reporting duty took effect on 11 September 2026, fifteen months ahead of the bulk of the regulation, and it binds products already on the market, not just new ones.⁷ Of all the obligations in a sweeping product-cybersecurity law, the one that lands first is the security-reporting one. If your autonomous system ships to Europe, the leading edge of the EU regulation is the one that touches your product’s safety case the soonest.

There is a reasonable objection to raise here, and it is worth answering before going further: this is European law. If your product never crosses the Atlantic, why should the CRA's clock mean anything to you?

Because a rule made for the European market rarely stays inside it. The pattern is well enough documented to have a name: the Brussels effect, coined by legal scholar Anu Bradford to describe the EU's ability to set standards that become global defaults, not by treaty or coercion, but through market gravity. A company that wants to reach the EU's roughly 450 million consumers has to meet its rules, and rather than run one product line for Europe and a looser one for everywhere else, firms often find it cheaper to build to the strict standard once and ship it everywhere. Data protection is the textbook case: even though the GDPR was written for the EU, companies like Apple and Google adopted its standards for their global operations rather than maintain two. The requirement propagates outward without anyone in Brussels lifting a finger.⁸

Functional safety is a cleaner illustration than privacy, though, because the standards at the center of this story are not EU exports at all. IEC 61508 and the emerging ISO/IEC work are global-consensus documents that US firms already build to. So the CRA does something subtler than force a foreign rule onto American products. It forces security into a standards ecosystem US manufacturers are already inside, and it does so on a deadline they do not control. You do not have to admire the mechanism to plan around it. If the connected safety-critical product you build is bound for Europe, or shares a design with anything that is, the leading edge of EU security regulation is already the floor you build on, whatever your own regulator has gotten around to requiring.

That said, the effect is a floor, not a prophecy. It describes where product standards tend to converge, not a guarantee that US law will mirror the CRA clause for clause, and the places where market segmentation is cheap are exactly where it does not reach. But for a networked product with one global design, the economics usually point one way.

Standards and laws are not the same animal, and that is the point

It would be easy to blur these together into a single “compliance landscape.” Resist the urge though, because the differences are where the insight lives. A standard like 61508 or a specification like 22440 is, to be clear, voluntary: a body of expert consensus you adopt to demonstrate you did the right thing in building your safety case. A regulation like the CRA is not voluntary at all. It is law, with deadlines and consequences, and it does not care whether you find its timelines convenient.

But watch how they inform one another. The law tells you that you must handle security on connected products; the standards increasingly tell you how to do it in a way that does not unravel your safety case. The standards give the law technical teeth; the law gives the standards urgency they don’t necessarily have on their own. One supplies the obligation, the other the methodology. They are converging not because anyone coordinated them, but because they are all responding to the same physical reality and autonomous systems’ landscape from different angles, and each covers a gap the others leave exposed.

The friction is the real story

None of this means safety and security fold together neatly. They pull against each other, and anyone who has shipped a product in the age of automation and AI feels it. Security wants to patch fast, the moment a threat event appears. Safety wants to change more methodically and slowly, revalidating deliberately, because an unproven change to a safety function carries its own risk. The CRA's 24-hour clock and the safety world's verification and validation lifecycle embody that tension exactly. Put them in one product and you have a genuine management problem, not a marketing message about “holistic assurance.”

That is what these three documents, read together, are actually telling you. Not that safety and security have merged. That they can no longer be governed in separate rooms, and that the hard, interesting work of the next few years is holding both at once, in the same product, under two clocks that tick at different speeds. Three entryways, one room. The only question is whether you get a head start or let the clock run out before moving forward.

_Endnotes

_{1. IEC 61508-1, scope exclusions regarding security of E/E/PE safety-related systems. See prEN IEC 61508-1:2025 catalogue listing: https://standards.iteh.ai/catalog/standards/clc/5551098d-3386-4248-903c-55ac84c3a837/pren-iec-61508-1-2025}

_{2. prEN IEC 61508-1:2025, described as integrating cybersecurity and human factors into the functional safety baseline: https://standards.iteh.ai/catalog/standards/clc/5551098d-3386-4248-903c-55ac84c3a837/pren-iec-61508-1-2025}

_{3. “Integrating AI in Safety-Critical Systems: Why ISO/IEC TS 22440 Changes the Game,” Automate.org, 15 August 2025: https://www.automate.org/news/integrating-ai-in-safety-critical-systems-why-iso-iec-ts-22440-changes-the-game}

_{4. prCEN/CLC ISO/IEC/TS 22440-3 scope note on how security threats can affect the safety of an AI system: https://genorma.com/en/standards/prcen-clc-iso-iec-ts-22440-3}

_{5. ISO/IEC CD TS 22440-1, development status (committee draft): https://www.iso.org/standard/89535.html}

_{6. Cyber Resilience Act, Article 14, reporting obligations of manufacturers (24 hour / 72 hour / 14 day duties). European Commission, CRA reporting obligations: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting}

_{7. European Commission, “The Cyber Resilience Act: Summary of the legislative text,” confirming entry into force 10 December 2024, main provisions from 11 December 2027, and Article 14 reporting obligations from 11 September 2026: https://digital-strategy.ec.europa.eu/en/policies/cra-summary}

_{8. The term and mechanism come from Anu Bradford, The Brussels Effect: How the European Union Rules the World (New York: Oxford University Press, 2020); first set out in Anu Bradford, "The Brussels Effect," Northwestern University Law Review 107, no. 1 (2012):1-68. https://trendsresearch.org/insight/the-brussels-effect-revisited-how-eu-rules-shape-global-choices/}