IoT Compliance: What You Have to Build, Not Just Document

A compliance program built around documentation passes right up until something happens. Then a regulator asks a question with a clock attached, and the answer depends on whether you built the capability months earlier.

The EU Cyber Resilience Act makes this concrete. Since September 11, 2026, manufacturers of products with digital elements on the EU market have had 24 hours to file an early warning on an actively exploited vulnerability. Twenty-four hours is not enough time to work out what is inside a product. You must already know.

That is the shape of modern IoT compliance. Not a binder. A set of things your organization can do on demand, with evidence attached.

What Is IoT Compliance?

IoT compliance is the practice of meeting the mandatory security, safety, and data requirements that govern connected products, then producing evidence that you met them, across the entire product lifecycle rather than at the point of sale.

Three features separate it from ordinary software compliance.

• The obligation follows the product into the field. A shipped device stays your responsibility for its service life, which for industrial and medical equipment runs a decade or more.
• Market access is the enforcement mechanism. Non-compliance does not usually start with a fine. It starts with a product that cannot be legally sold.
• You are accountable for code you did not write. Chipset vendors, board support package suppliers, and open source maintainers wrote most of what ships, and the regulation names you.

This guide covers the cybersecurity dimension, which is where the binding obligations for device manufacturers have concentrated. IoT compliance in the wider sense also spans radio and RF certification, product safety marking, and data privacy law, and those run on separate processes with separate labs.

For the catalogue of which regulations apply to you and what non-compliance costs, we cover that separately in how IoT security challenges impact regulatory compliance. This page is about what you build to satisfy them.

Every row describes something an engineering team builds, not something a compliance team writes.

1. Design for the Requirement, Not for the Audit

Security added late produces products that pass review and fail in the field. Regulators have converged on the same conclusion, which is why secure development now appears as an obligation rather than a recommendation.

Adopt a named framework. NIST SP 800-218 (SSDF) for general secure development, IEC 62443 for industrial systems. The value is not the framework itself. It is that an assessor recognizes it, so your evidence maps to something they already understand.

Model threats before you write code. Threat modeling is the cheapest point at which to remove an entire class of vulnerability, because at design time removing it costs a decision rather than a recall.

Make the evidence a build artifact. If your secure development evidence is assembled by hand before an audit, it describes what you remember rather than what happened. Evidence generated by the pipeline is reproducible, and reproducible is the standard an assessor applies.

2. Ship Secure by Default

Secure by default means the device is safe in the configuration a customer actually receives, before anyone changes a setting. Most of the requirements below trace directly to a named regulatory obligation.

A device that ships correctly configured removes an entire category of compliance finding, because the finding never gets generated.

3. Treat the Supply Chain as In Scope, Because Regulators Do

Most of your attack surface arrived from a supplier, and no regulation accepts that as an excuse.

Black Duck's 2026 Open Source Security and Risk Analysis report, based on audits of 947 commercial codebases, found open source in 98% of them, with components per codebase up 30% year over year. It also found 92% of codebases contained components four or more years out of date, and 93% contained components with no development activity for at least two years.

On a device with a 10 year service life, an unmaintained component has no upstream fix path. When a vulnerability lands in it, there is no patch to apply, and the compliance question becomes what you do instead.

Three things to put in place:

• Assess suppliers formally, covering their development practices, disclosure process, and patching commitments, before a component enters a design.
• Put security obligations in the contract, specifying disclosure timelines and patching responsibility. A supplier with no contractual duty to tell you about a vulnerability will not.
• Verify what suppliers send you. A supplier SBOM is a claim. Analyzing the binary they shipped is how you check it, and it is the only method available when the supplier will not release source.

4. Test Continuously, Because the Obligation Is Continuous

Point-in-time testing satisfies a point-in-time question. Every regulation in the table above imposes an ongoing duty.

Build the testing into the pipeline rather than the calendar. Software composition analysis on every build, static and dynamic analysis on first-party code, and penetration testing on firmware before major releases and periodically afterward, since physical and firmware-level attacks are the ones automated scanning tends to miss.

The harder problem is what to do with the results. Scanners produce more findings than any team can remediate, and a backlog is not a defense. Prioritization that survives scrutiny asks whether the vulnerable code is present in the shipped image, whether it is reachable, and whether anyone is exploiting it. A finding that fails the first question is not a deferred fix.

That ordering also produces the artifact an assessor wants, which is a documented and repeatable reason why you patched one thing and deferred another.

5. Make the SBOM the Evidence, Not the Deliverable

Regulators now ask for a software bill of materials by name. The CRA requires one in technical documentation. FDA Section 524B(b)(3) requires one covering commercial, open-source, and off-the-shelf components.

Teams generate it from the build system, where it comes out clean, validates against the schema, and describes a different artifact than the one that shipped.

Your build manifest records what you intended to include. The binary records what actually shipped. They disagree whenever a contract manufacturer swaps a library version, a supplier image carries an undeclared dependency, or a component arrives statically linked inside a vendor blob.

An SBOM that holds up needs to be generated from the shipped artifact, regenerated automatically on every release, complete through transitive dependencies, and populated with per-component maintenance status and end-of-support dates. That last field is where most submissions fail, because an inventory that cannot tell you whether a component is still maintained is not a risk artifact.

Generate SBOMs from firmware with no source code required. See the SBOM Management data sheet.

6. Run Compliance as an Operating Capability

The three practices below are what separate teams that respond to regulation from teams that are surprised by it.

Watch the regulations that are not yet binding. The CRA's December 2027 obligations are the ones to be building for now, because secure development evidence and vulnerability handling processes take longer to stand up than the deadline leaves.

Automate the reporting path before you need it. Under CRA Article 14 you have 24 hours for an early warning, 72 hours for a fuller notification, and 14 days for a final report once a corrective measure is available. Know who files, through which platform, with what authority, before the first one is due.

Put engineering, security, legal, and regulatory affairs in the same review. Compliance gaps are almost always found at the seam between two functions that each assumed the other owned it.

Key Takeaways

• IoT compliance is capability, not documentation. Every binding obligation in the table above describes something the organization must be able to do on demand.
• The nearest CRA deadline has already passed. Article 14 reporting has applied since September 11, 2026, and it reaches products you shipped years ago.
• Secure by default removes findings at the source. A device that ships correctly configured never generates the finding.
• Supplier code is your compliance problem. With 92% of codebases carrying components four or more years out of date, unmaintained dependencies are the dominant long-tail risk on a 10 year product.
• The manifest is not the inventory. Build records describe intent. The binary describes what shipped, and for supplier-provided firmware it is the only method available.

Where to Start

One first move. Take the most recent product you shipped and answer a single question: how long would it take to produce a complete, accurate component inventory for it right now? If the answer is longer than 24 hours, you do not currently have an Article 14 capability, whatever your documentation says.

Three questions worth putting to your team this month:

1. Which of our products ship with a universal default credential, and do we know that or assume it?
2. Who files the CRA early warning, by name, and what is the escalation path outside business hours?
3. For every third-party component in our current release, can we state its maintenance status and end-of-support date?

We build the component inventory from shipped firmware and binaries rather than the build manifest, then track those components against exploit intelligence over the product's life. To see that against your own device, request a walkthrough.

FAQ

What is IoT compliance and why is it important for businesses?

IoT compliance means meeting the mandatory security, safety, and data requirements governing connected products, and producing evidence you met them across the product lifecycle. It matters because enforcement usually runs through market access rather than fines. A non-compliant product cannot be legally sold, which turns a compliance gap into a revenue problem before it becomes a legal one.

What are the primary global regulatory standards for IoT security?

The EU Cyber Resilience Act, whose Article 14 reporting duty applied from September 11, 2026 with full application from December 11, 2027. The UK PSTI Act, in force since April 29, 2024. FDA Section 524B for US medical devices, effective March 29, 2023. NIS2 for operators in critical sectors. IEC 62443 for industrial systems, and NIST SP 800-218 as the secure development framework most others reference.

Why is IoT compliance critical for preventing data breaches and legal liability?

The controls regulations mandate are the ones that close the most-used attack paths, including default credentials, unsigned firmware updates, and unmonitored third-party components. Liability follows separately: once a requirement is written into law, failing to meet it converts a security incident into a documented regulatory failure, which is a materially worse position than the same incident with compliance evidence in hand.

Does the EU Cyber Resilience Act require an SBOM from September 2026?

No. The obligation that applied from September 11, 2026 is Article 14 reporting of actively exploited vulnerabilities and severe incidents. SBOM and vulnerability handling requirements sit in Article 13 and Annex I Part II and apply from December 11, 2027. In practice the 24 hour reporting clock leaves no time to build an inventory, so the earlier date creates the same operational need.

What does the UK PSTI Act require from IoT manufacturers?

Three things: no universal default passwords, a published minimum period for which security updates will be provided, and a working vulnerability disclosure route. The Act received Royal Assent in December 2022, but the security requirements came into force through the PSTI Regulations 2023 on April 29, 2024, and apply to products sold from that date regardless of when they were manufactured.

How is IoT compliance different from IT security compliance?

IT compliance governs systems you operate and can patch on your own schedule. IoT compliance governs products you sold, which run in someone else's environment for a decade, update through constrained channels, and contain code you licensed rather than wrote. The obligation attaches to the product and follows it into the field.

Can you be compliant without access to your suppliers' source code?

Yes, and regulators have accepted that source code is frequently unavailable. What they do not excuse is not knowing what is in the component. Analyzing the shipped binary produces the inventory and the vulnerability picture without source code or supplier cooperation, which is why it is the practical route for firmware built from third-party parts.

Where should a manufacturer start with IoT compliance?

With inventory, because every other obligation depends on it. Reporting, patching, technical documentation, and supplier assurance all assume you can list what is in a product and say whether each component is still maintained. Establish that first, then build the reporting and disclosure paths on top of it.