Connected product makers now face legal baselines in the UK and the EU, yet many still ship devices with shared credentials, no published support period and no way for a researcher to report a flaw. This model uses NHI Mgmt Group's five levels (Ad hoc, Developing, Defined, Managed and Optimised) to score an IoT product security programme across six capability areas: secure design and development, device identity and credentials, vulnerability handling and disclosure, software updates and support, software supply chain and SBOM, and conformity with ETSI EN 303 645, the UK PSTI regime and the EU Cyber Resilience Act (CRA). It is written for manufacturers, product security leads, PSIRT managers and the compliance teams preparing for CRA obligations. It scores the maker's programme, not the buyer's deployment; for operating devices in an enterprise, read the IoT Security Guide.
Key takeaways
- The legal floor is Level 2, not Level 3: UK PSTI has required no universal default passwords, a published vulnerability reporting route and a stated support period since 29 April 2024; meeting only that is Developing.
- CRA reporting starts before the main obligations: manufacturers must report actively exploited vulnerabilities and severe incidents from 11 September 2026, with the main obligations applying from 11 December 2027.
- Every device is a machine identity: unique per-device credentials, keys out of source code and protected storage are where most programmes are weakest.
- Updates are a lifecycle promise: Defined maturity means a signed, verified update path and a support period the business has funded, not just a firmware download page.
- Measure response, not policy: higher levels track time from report to fix and the share of the fleet running a supported version.
The five levels
| Level | Name | What it looks like |
|---|
| 1 | Ad hoc | Security depends on individual engineers. Shared default credentials, debug interfaces left open, keys and API tokens in firmware or source code. No vulnerability contact, no defined support period, updates issued irregularly or not at all. |
| 2 | Developing | The legal minimum: unique or user-set passwords, a published vulnerability reporting route, a declared support period. Some secure coding practice and pre-release testing, but no product security owner across lines and no consistent update mechanism. |
| 3 | Defined | A product security policy and owner. Threat modelling for each new product, secure development lifecycle gates, unique per-device credentials and protected key storage, signed and verified updates, a PSIRT process with timelines, an SBOM per release and an EN 303 645 conformance statement. CRA reporting process tested. |
| 4 | Managed | Metrics across the portfolio: time to fix by severity, share of devices on supported firmware, components with known exploited vulnerabilities. Third-party assessment against EN 303 645 or equivalent, CRA technical documentation maintained, supplier security requirements enforced. |
| 5 | Optimised | Fleet telemetry informs threat models, vulnerability classes are eliminated by design (memory-safe components, hardware roots of trust), disclosure is welcomed with a bug bounty, and lessons from incidents and reports change architecture across the product range. |
Capability areas
Score each area at the highest level where every statement holds for all products on the market and in development, not a flagship line only.
| Area | Level 1 Ad hoc | Level 3 Defined | Level 5 Optimised |
|---|
| Secure design and development | No threat model, no security requirements | Threat model per product; security requirements from EN 303 645 and NIST IR 8259A capabilities; code review and testing gates; unused interfaces disabled | Vulnerability classes removed by design; secure boot and hardware roots of trust standard; design reviews informed by field data |
| Device identity and credentials | Shared default passwords; keys in firmware | Unique per-device credentials; no hard-coded critical security parameters in source; secure persistent storage; best practice cryptography for authentication | Hardware-backed device identity; certificate lifecycle automated; credentials for backend services scoped per device and rotated |
| Vulnerability handling and disclosure | No contact; reports ignored | Published disclosure policy with acknowledgement and status timelines; PSIRT triage; CVE assignment; CRA early warning within 24 hours and notification within 72 hours of awareness rehearsed | Bug bounty; advisories with machine-readable data; root cause analysis feeds design standards |
| Software updates and support | No update mechanism or irregular releases | Signed updates verified on device; defined support period published at point of sale; updates simple to apply | Staged rollouts with automatic rollback; high fleet update rates measured; support period funded in product business cases |
| Supply chain and SBOM | Components unknown | SBOM per release; component vulnerability monitoring; supplier security requirements in contracts | Supplier assurance audited; components with known exploited vulnerabilities blocked from release; hardware and firmware bill of materials maintained |
| Conformity and regulation | Unaware of obligations | Conformance statement against EN 303 645; PSTI statement of compliance; CRA product classification and conformity route chosen; technical documentation started | Third-party certification or labelling where markets require it; regulatory changes tracked and built into the roadmap |
Regulatory anchors for the levels
| Instrument | Status as published | What it means for the score |
|---|
| ETSI EN 303 645 V3.1.3 | European Standard, 13 provision groups from no universal default passwords to validating input data | Mandatory provisions such as 5.1 (no universal default passwords), 5.2 (vulnerability reports), 5.3 (updates) and 5.4 (secure storage of security parameters) form the Level 3 baseline |
| UK PSTI regime | Applies since 29 April 2024 to most consumer connectable products | Three requirements (passwords, reporting route, support period) set the Level 2 legal floor for UK sales |
| EU Cyber Resilience Act | In force 10 December 2024; reporting from 11 September 2026; main obligations from 11 December 2027 (European Commission) | Essential requirements, a manufacturer-set support period, conformity assessment and CE marking; important and critical product classes need stricter assessment routes |
| NIST IR 8259 Rev. 1, IR 8259A and IR 8259B | IR 8259 Rev. 1 final 20 April 2026; 8259A technical and 8259B non-technical baselines | Activities across pre-market and post-market phases, and device capabilities (identification, configuration, data protection, interface access, software update, state awareness) |
CRA penalties for breaching the essential requirements can reach EUR 15 million or 2.5 per cent of worldwide annual turnover, whichever is higher, under Article 64. Status and dates can change through delegated and implementing acts; check the Commission's CRA pages before relying on a date. See the EU Cyber Resilience Act Guide, the ETSI EN 303 645 Consumer IoT Guide and the UK PSTI Act Product Security Guide.
Evidence for each level
| Level | Acceptable evidence | Not sufficient on its own |
|---|
| 2 Developing | PSTI statement of compliance; published reporting route and support period; password design note | A marketing "secure" claim |
| 3 Defined | Threat models; SDL gate records; EN 303 645 implementation conformance statement; update signing design; PSIRT procedure with timelines; SBOM per release; CRA reporting runbook and test record | A penetration test of one product |
| 4 Managed | Portfolio metrics; third-party assessment reports; CRA technical documentation; supplier audit results | Counts of CVEs published |
| 5 Optimised | Architecture changes traced to field data or reports; bug bounty statistics; eliminated vulnerability classes | Absence of reported vulnerabilities |
Self-assessment questions
- Credentials: does any product, in any market, ship with a password, key or token shared across devices? Are backend service keys kept out of firmware and source code? In the HPE Aruba Instant On case, hard-coded credentials (CVE-2025-37103) were shared across devices on firmware 3.2.0.1 and earlier, could not be changed by owners, and allowed administrator login until firmware 3.2.1.0; HPE stated there was no workaround.
- Backend keys: if your source code leaked tomorrow, which provider keys would an outsider gain, and could you rotate them without taking devices offline? In the Rabbit R1 case, working third-party API keys sat in source code, and one improperly revoked key caused a temporary outage.
- Threat modelling: does every new product have a threat model reviewed before design freeze?
- Interfaces: are debug and unused network interfaces disabled or protected in production builds?
- Disclosure: is there a published policy with acknowledgement and status timelines, and how long did the last three reports take to fix?
- CRA reporting: could you send an early warning within 24 hours of becoming aware of an actively exploited vulnerability, and has the process been rehearsed?
- Updates: are updates signed and verified on the device, and what share of the fleet runs a supported version?
- Support period: is the support period published where the product is sold, and is it funded in the business case?
- SBOM: can you say within a day which products contain a newly announced vulnerable component?
- Conformity: do you know each product's CRA class and conformity assessment route?
Moving up: roadmap
From Ad hoc to Developing
- Remove universal default passwords from all products and publish a vulnerability reporting route and a support period for each. See the Vulnerability Disclosure Policy Template.
- Name a product security owner across product lines.
- Scan firmware and source for hard-coded credentials and keys.
From Developing to Defined
From Defined to Managed
- Report portfolio metrics quarterly to leadership.
- Commission third-party assessment against EN 303 645 or a market label scheme.
- Maintain CRA technical documentation and supplier security requirements; audit key suppliers.
- Block releases containing components with known exploited vulnerabilities.
From Managed to Optimised
- Use fleet telemetry (with privacy safeguards) to update threat models.
- Remove vulnerability classes by design, such as memory-safe components for parsers and hardware roots of trust.
- Launch a bug bounty and publish machine-readable advisories. See the Bug Bounty and Vulnerability Disclosure Guide.
Metrics that show progress
| Metric | What it shows | Level where it becomes expected |
|---|
| Products with shared credentials or hard-coded keys (target zero) | Identity baseline | 2 |
| Median days from vulnerability report to fix, by severity | PSIRT effectiveness | 3 |
| Share of products with a current SBOM and conformance statement | Documentation coverage | 3 |
| Share of fleet on a supported firmware version | Update reach | 4 |
| Releases blocked for known exploited components | Supply chain control | 4 |
| Hours from awareness to CRA early warning in exercises | Reporting readiness | 4 |
Small and large manufacturers
| Aspect | Small maker or start-up | Large manufacturer with many product lines |
|---|
| Product security ownership | One named engineer with time allocated, backed by a lead who can stop a release | Central product security office setting standards, with security champions in each product team |
| PSIRT | Shared inbox with a named owner, a written timeline and an external partner for triage peaks | Dedicated PSIRT, CVE Numbering Authority status, coordinated advisories |
| Conformity | Self-assessment against EN 303 645 using the implementation conformance statement; third-party assessment where retailers or the CRA class require it | Third-party assessment for every product family and a tracked CRA conformity route per class |
| Realistic 12-month target | Level 3 in device identity, updates and disclosure | Level 4 in all six areas |
Small makers get the most from fixing credentials and the update path first, because those two areas drive most field compromises and both sit inside the legal baseline. Large makers should standardise shared components (bootloader, update client, credential provisioning) once and reuse them, so maturity rises across every product line together. See the Becoming a CVE Numbering Authority Guide.
Where identity fits
Each device is a non-human identity with a lifecycle: a credential injected at manufacture, an identity enrolled with the backend at onboarding, keys rotated during service and revoked at end of life or resale. The backend services the device calls hold their own API keys and certificates, which are often the real prize for attackers, as the Rabbit R1 case shows. A Level 3 programme documents that lifecycle; a Level 4 programme measures it, for example the share of devices with certificates inside their validity window and the time to revoke a compromised device. See the Identity for IoT Fleets Guide and the IoT Device Onboarding Guide.
Common failure patterns
- Compliance as the ceiling: PSTI statements are filed and the programme stops, leaving updates unsigned and keys in firmware.
- Keys in code: provider API keys and signing keys sit in source or firmware, so one leak exposes every device and service.
- Support period nobody funded: the published period outlives the team and budget that can deliver updates.
- Disclosure inbox with no owner: reports arrive at a generic address and age without acknowledgement, breaking the published timelines.
- No rotation path: keys cannot be revoked without breaking devices, so exposed keys stay live.
- Late CRA preparation: reporting from September 2026 is treated as a 2027 problem.
Framework mapping
| Capability area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | EN 303 645 provision |
|---|
| Secure design and development | PR.PS-02 | SA-8, SA-11, SA-15 | 5.6 Minimise exposed attack surfaces |
| Device identity and credentials | PR.AA-03 | IA-5 | 5.1, 5.4 |
| Vulnerability handling | ID.RA-08 | RA-5, SI-2 | 5.2 |
| Updates and integrity | PR.PS-02 | SI-2, SI-7 | 5.3, 5.7 |
| Supply chain and SBOM | GV.SC-05 | SR-3, SR-4 | Not a provision group; supports 5.2 and 5.3 |
Practitioner checklist
- Score all six areas across the whole portfolio and keep the evidence.
- Confirm zero shared default credentials and zero hard-coded keys in shipping products.
- Publish a disclosure policy with timelines and measure time to fix.
- Rehearse the CRA 24-hour early warning and 72-hour notification process.
- Sign and verify updates and publish a funded support period at point of sale.
- Produce an SBOM per release and monitor components for exploited vulnerabilities.
- Write EN 303 645 conformance statements and classify products under the CRA.
- Set a target level per area for the next 12 months and reassess annually.
Standards and references
Related NHI Mgmt Group resources: IoT Security Guide · NIST IR 8259 IoT Device Cybersecurity Baseline Guide · Vulnerability Disclosure Maturity Model · EU Cyber Resilience Act Executive Briefing