Reporting obligations started.
Sweden and Poland
IoT Security & Reliability Baseline Assessment
An independent lab assessment of one connected product and its ecosystem — the sensor, the hub, the app, and the network behaviour that can be observed — with security observations, reliability measurements, and documented limitations.
This is independent product assurance. It is not official certification, and it is not a Cyber Resilience Act conformity assessment.
Who it is for
Three decisions, three reports
The catalogue is written for EU companies of about 5–100 employees with no in-house IoT security team. The same work answers a different question depending on who is asking.
-
Manufacturers and OEMs
Engineering action report
For a small company building a connected product. The report names what to change in the product and its ecosystem, tied to case IDs, before you ship or scale.
-
Brands, importers, and distributors
Supplier qualification report
For a company putting its name on a product made in someone else’s factory. The report says whether this product, as supplied, is fit to source.
-
Integrators
Deployment suitability report
For a company about to install a product in someone else’s building or system. The report says whether it is fit for that deployment.
Deliverables
Evidence, then a recommendation
Every case is marked Pass, Fail, N/A, Not Tested, or Inconclusive. The recommendation is one of four sentences. Nothing is collapsed into a score.
-
2 pages
Decision summary
The recommendation, the conditions or blockers, and the limitations that bound them. Written for the person who has to decide.
-
10–15 pages
Technical report
Each case with a verdict, the observation, and a pointer to the evidence. Reliability figures include the method and the conditions.
-
File
Machine-readable results
One record per case. JSON unless scoping agrees another format. There is no field for a combined score.
Verdicts
- Pass The observation met the criterion agreed for that case.
- Fail The observation did not meet the criterion.
- N/A The case does not apply to this product’s architecture. Hub power recovery is N/A when there is no hub.
- Not Tested The case was in scope but was not run.
- Inconclusive The case was run, and the evidence does not support Pass or Fail.
Recommendation
- Proceed No failed case blocks the decision named in the scope. This is not a statement that the product is secure in general. It covers this catalogue, this decision, and the unit tested.
- Proceed with conditions The decision can go ahead only if named conditions are met. Each condition cites a case ID.
- Do not proceed pending remediation A failed case blocks the decision until it is fixed and, where agreed, retested.
- Insufficient evidence The lab cannot support a proceed or do-not-proceed recommendation from what was supplied or what could be observed.
22 cases
A fixed catalogue
One product, the ecosystem it needs, and the same 22 cases every time. Scope can mark a case N/A. It does not invent a new method for each engagement.
-
SEC-01 – SEC-08 · 8
Security
What the product exposes, who can control it, how it talks, where it connects, and whether an update or a reset does what an owner would expect.
-
REL-01 – REL-08 · 8
Reliability
Whether the product can be set up, whether it does the job it claims, and whether it recovers when the network or the power does not cooperate.
-
GOV-01 – GOV-04 · 4
Lifecycle and privacy
What the supplier says about support, vulnerability reports, personal data, and firmware integrity — checked against documents and against what the product actually does.
-
INT-01 – INT-02 · 2
Interoperability
Whether the product works in the ecosystem you named, and whether it can be taken out and put back into service.
Mapping only
Read against known references
Results are mapped to four public references so a reader can see which themes a case relates to. A pass is not conformance, and it is not a presumption of conformity.
-
ETSI EN 303 645
Cyber Security for Consumer Internet of Things: Baseline Requirements. The report points at these themes where a reading is fair: exposed interfaces, credentials, updates, communications, data deletion, resilience.
-
ETSI TS 103 701
Conformance Assessment of Baseline Requirements. It describes how a conformance assessment against EN 303 645 is structured. This lab does not carry out that assessment.
-
OWASP IoT Security Testing Guide
A testing guide for IoT products across the device, the communications, and the app. It is a guide, not a standard, and not a certificate.
-
NIST IR 8259A
IoT Device Cybersecurity Capability Core. Used as a second reading of the same evidence: identity, configuration, data protection, access to interfaces, software update, and cybersecurity state awareness.
Context, not a legal opinion
The Cyber Resilience Act is already in its reporting phase
The main requirements apply.
That is Regulation (EU) 2024/2847. This assessment does not discharge a manufacturer’s duties under it, and it is not a conformity assessment. It gives a small team evidence and a recommendation they can act on. EUR-Lex text.
Indicative
Fees, before a written quote
Figures are in euro, before VAT and before shipping the sample. A short scoping note confirms the number before any work starts.
-
Basic assessment
€400–800The full catalogue on one product and its ecosystem, plus the three deliverables. Suited to a straightforward device with one app and, if it has one, a single hub.
-
Extended review
€1,000–2,000The same catalogue with more time on communication security, network destinations, update behaviour, and supplier documents. Suited to a busier ecosystem, or to a sourcing decision rather than an internal engineering check.
-
Retest
€200–500A shorter run of the failed or inconclusive cases you have remediated, with an updated summary. Not a new full assessment.