IoT Device security requirements — check device configs free

19 findings - 15 errors and 4 warnings - in one 39-line device.yaml, for firmware and embedded engineers shipping radio devices into the EU or UK. Six of those 15 errors, exactly as the tool prints them:

L9   error  default_password           PSTI Sch. 1 para. 1 / RED Art. 3(3)(d)
L10  error  telnet_enabled             RED Art. 3(3)(d) / EN 18031-1
L21  error  tls_verification_disabled  RED Art. 3(3)(e) / EN 18031-2
L28  error  update_signature_off       RED Art. 3(3)(d) / EN 18031-1
L36  error  wrong_harmonised_standard  EN 303 645 is not harmonised here
L39  error  support_period_lapsed      ended 2026-06-30, 75 days ago

That file is _fixtures/dirty.yaml, the sample shipped with the extension - a fictional cellular gateway's default configuration, read on 2026-09-13. No code was written to produce any of those findings. Every one of them sits in the shipped defaults: the admin password, the telnet service, the certificate check, the OTA block, and two citations in the compliance section that are simply wrong.

Why a config file decides this

Since 1 August 2025, radio equipment placed on the EU market has had to meet the cybersecurity requirements of Delegated Regulation (EU) 2022/30 under the Radio Equipment Directive: Article 3(3)(d) network protection, 3(3)(e) personal data and privacy, 3(3)(f) protection from fraud. The harmonised standards cited for those limbs are EN 18031-1, -2 and -3. In the UK, PSTI has been in force since 29 April 2024, and its Schedule 1 asks three things a config file can answer: no universal default passwords, a published vulnerability-reporting contact, and a published minimum period for security updates.

The two findings a chatbot will not give you

Ask a general assistant which standard to cite and it will often say EN 303 645. That is the ETSI consumer-IoT baseline. It is not a harmonised standard under the delegated regulation, so citing it alone gives no presumption of conformity - and the line reads as done when it is not. The second is a date: the requirements were originally set for August 2024, then deferred by amendment (EU) 2023/2444 to 1 August 2025. Declarations written in that year still carry the old date, and a reviewer who reads August 2024 concludes the document was never revisited.

Both are rules here, with a third no generic tool asks: en18031_part_missing. EN 18031 without a part is not a citation - -1 is network protection, -2 is personal data and privacy, -3 is protection from fraud.

The line that moves

support_until: 2026-06-30 is not a string match; it is compared against today. Read on 2026-09-13, the published support period ended 75 days ago, so the security-update statement shipped with units already in the field is no longer true. Read the same file on 15 January 2026 and it is a warning with 166 days left - time to extend the date or write the end-of-support notice. Same file, different day, different answer.

The corrected version of that config - unique-per-unit passwords, SSH instead of telnet, mqtts on 8883, signed OTA over HTTPS, telemetry off with consent required, EN 18031 cited by part - returns 0 findings.

A contract firmware engineer at $120 an hour bills roughly $480 for the half day one such file takes by hand against Article 3(3)(d)(e)(f) and PSTI Schedule 1, and it repeats every build, because defaults drift back.

The next date is on the calendar: the EU Cyber Resilience Act reporting duties started on 11 September 2026 - 24 hours, then 72 hours, then 14 days. Same device, shorter clock.

Checking one file is free and complete: all 19 rules resolve with line numbers and clauses, no key, offline, and the same engine runs in the browser with nothing installed. The paid tier is a different job: sweep every config in the workspace and export a dated evidence pack, Markdown and CSV, mapping each finding to its article and clause. $29 once.