For connected products, that usually means answering two questions early. Does EN 18031 apply to the product, and which parts of the product ecosystem need to be included in the assessment?
Start Your Free EN 18031 Assessment
This page is for teams that already know EN 18031 may be relevant and need a practical way to determine scope.
A good scope assessment helps you answer:
whether the product falls within the relevant cybersecurity requirements
which EN 18031 part is likely to matter most
which product components need review
which teams need to be involved
what should move into requirements mapping next
What Should Be Included in Scope
In many cases, scope extends beyond the physical product. Your assessment may need to include:
the radio-enabled device
companion mobile or web apps
backend or cloud services
account creation and login flows
remote administration functions
software and firmware update paths
storage or transfer of personal, traffic, or location data
product support processes tied to security or vulnerability handling
A narrower review often looks simpler at first, but it creates gaps later when teams start documenting controls and responsibilities.
Need more information?
By contacting QIMA you agree to our privacy policy and terms and conditions.
How to Assess Device, App, and Backend Together
A useful scoping exercise should follow the way the product actually works.
Start with the product journey:
how the product connects
how users access it
what systems it depends on
where data moves
how updates are delivered
what happens when a security issue is found
This makes it easier to identify whether the product relies on components outside the hardware itself.
Signals That Scope May Be Broader Than Expected
Scope is often broader when the product:
depends on a companion app for setup or control
sends data to a cloud platform
processes personal, traffic, or location data
supports remote access or remote configuration
receives firmware or software updates
includes user accounts, permissions, or admin roles
handles payments, transfers, or stored value
If several of these are true, the review should usually cover more than the device alone.
Common Scoping Mistakes
Teams often run into problems when they:
treat hardware as the full product boundary
ignore backend dependencies
leave app flows out of the review
do not define ownership between engineering, compliance, and security
start evidence collection before scope is agreed
mix product features with regulatory scope without documenting the link
These issues usually cause delays later, especially when requirement mapping begins.
What a Good Scoping Output Looks Like
A useful scope assessment should produce something concrete. At minimum, teams should leave with:
the likely standard part or parts involved
a documented boundary across device, app, and backend
a list of systems, functions, and flows included in review
identified owners for the next step
a clean handoff into requirements mapping and evidence preparation
How Cyberexpert Helps
Cyberexpert helps teams structure this work from the start.
With Cyberexpert, teams can:
assess whether EN 18031 is relevant to the product
define scope across device, app, and backend
identify the systems and flows that need review
organize the next step for requirements mapping
create a clearer starting point for documentation and evidence work