Which device security rules apply where you sell, and when

In short

• India and the EU now treat device security as a legal gate for some products: cameras and routers in India, connected and radio products in the EU.
• The US and international frameworks are voluntary, but buyers, labels and tenders use them as the bar.
• A firmware analysis decides or helps with 218 of the 720 provisions we track; the rest is people and process, so staff for it now.

The 14 frameworks at a glance

Which frameworks apply depends on what you sell and where; these are the 14 that FDIE by Magdox maps evidence to.

We do not offer the UK PSTI regime, UN R155 or ISO/SAE 21434, so plan for those separately if those markets matter to you.

India: two gates and one code

In India, cameras and routers need a security test before sale, while other consumer devices have a voluntary code.

ER-01 covers CCTV and IP cameras registered with the Bureau of Indian Standards (BIS). It asks for signed boot images and updates, no hard-coded passwords, closed debug ports and keys unique to each device, and a lab tests the camera itself.

NCCS ITSAR covers IP routers and Wi-Fi CPE such as home routers, fibre modems and access points. Its documents are long, with 179 clauses for routers and 133 for Wi-Fi CPE. A lab named by NCCS, the national telecom security centre, tests most of them on the device. Our ITSAR and TEC 31318 post shows which ones firmware can answer.

TEC 31318 is a voluntary code for consumer IoT, revised in November 2025 to follow ETSI EN 303 645. It is free to adopt, and the work carries over to buyers abroad.

European Union: one regulation, one directive winding down

Every connected product sold in the EU falls under the Cyber Resilience Act, and radio products also meet the Radio Equipment Directive until December 2027.

The CRA applies to hardware and software with a data connection. From 11 September 2026, makers must report actively exploited vulnerabilities, even for products already sold. From 11 December 2027, every product must also meet the essential requirements of Annex I. Routers, modems and smart home security cameras are important products of class I, which limits checking them yourself (self-assessment).

EN 18031 is the harmonised standard for those rules, meaning the EU standard that shows a product meets them. It comes in three parts: internet-connected radio, personal data and payments. In April 2026 the EU published the act that ends those rules on 11 December 2027, when the CRA takes over.

The prEN 40000 drafts will become the CRA's own standards, but none is published or cited yet. So meeting them does not yet count as legal proof of meeting the CRA, which the law calls a presumption of conformity. We map them so you can see the gap early.

United States: voluntary baselines

Nothing here is law for device makers, yet the baselines of NIST, the US standards institute, shape labels and buyer questionnaires.

NIST IR 8259A lists six things a device should be able to do, from secure updates to reporting its security state. NIST IR 8425 widens that to the whole product, with its app and cloud, and adds documentation and support duties.

The voluntary Cyber Trust Mark of the FCC, the US communications regulator, builds on 8425. But its lead administrator withdrew in December 2025, and the FCC reopened applications in January 2026. Check its status before planning around the label.

International: what global buyers name

These three are not tied to one market. ETSI EN 303 645 is the consumer IoT baseline behind TEC 31318. IEC 62443-4-2 sets requirements for industrial components at security levels 1 to 4, and industrial gateway buyers often ask for it.

OWASP FSTM is not a rule at all but a nine-stage way to test firmware.

What a firmware analysis can prove

It can prove what is inside the image and how it is built, but not how your company works. The counts below come from our catalogue of 13 frameworks, leaving out FSTM because it is a method.

It is strong on what an image shows: default passwords, weak cryptography, open services, unsigned updates and known vulnerabilities. It cannot see factory key loading, debug pads, your manual, or how fast you fix bugs. That part is policies, records and lab tests.

Keeping one set of evidence for every market

Each product carries its device type and markets, and the app shows only the frameworks that apply to it.

• The overview groups frameworks by market, with gaps in mandatory frameworks first.
• Frameworks that do not apply are listed with the reason; ER-01 does not apply to a router, for example.
• Each provision says how it is decided: automatic, partly automatic or needs evidence.
• Your team attaches a document, test report, procedure, link or undertaking where a provision asks for one.
• Nothing passes without a device check, product data, evidence or a sign-off.

This is evidence and gap finding, not certification. A lab or a notified body, an approved EU assessor, makes the final call.

Decisions for this quarter

Most of this cannot be handed to a lab, so here are the calls we would make now.

• Map every model to its markets: a Wi-Fi camera sold in India and the EU meets ER-01, the CRA and EN 18031 at once.
• Name an owner for the people side: someone must own policies, support periods and bug handling, not only the firmware.
• Budget lab time per firmware version: an ER-01 certificate names the firmware version and its hash, and each change needs a record.
• Ask vendors a plain question: which provisions does your tool decide on its own, and which need our documents? A vendor that claims to cover everything is overselling.