Common EN 18031 Gaps Before Launch, Updates, Access Control, Vulnerability Handling
EN 18031 readiness often breaks down in places that look minor during development but become serious problems close to launch. A device may support updates, but only part of the product is actually covered. Authentication may exist in the app, while other interfaces remain too open. Vulnerability handling may be discussed internally but not documented in a way that supports launch readiness. In products that fall under the Radio Equipment Directive, these are not side issues. They directly affect how well the product is prepared for market access, documentation, and assessment.
The timing matters. The European Commission activated Articles 3(3)(d), (e), and (f) for certain categories of radio equipment through Delegated Regulation (EU) 2022/30, with application from 1 August 2025. In January 2025, EN 18031-1, EN 18031-2, and EN 18031-3 were cited in the Official Journal, which made them the practical standards framework many manufacturers now need to work through before launch.
The most useful question before release is not whether EN 18031 has been reviewed. It is whether the product still has gaps in secure updates, access control, or vulnerability handling that could weaken both security and the evidence needed to support compliance.
If you are still validating scope before launch, Cyberexpert can help identify which EN 18031 requirements apply to your product, structure the assessment across device, app, and backend, and prepare evidence earlier, before testing or certification timelines create pressure. For a broader regulatory overview, you can also read our Guide to Cybersecurity Compliance for Consumer Products.
Why These Gaps Show Up Before Launch
Launch pressure tends to expose structural weaknesses that looked manageable earlier in development. During design, a temporary debug path feels harmless. During testing, a skipped password step feels convenient. Close to release, those same decisions become harder to defend because they now affect the live product, the release candidate, and the technical file.
A second reason is fragmentation. One team owns the device firmware, another owns the cloud service, another handles the mobile app, and nobody fully owns the compliance story across all of them. The result is a product that looks finished from a feature perspective, but still has unanswered questions around authentication, maintenance, and post-market vulnerability handling.
A third reason is timing. Some issues only become visible when someone asks for concrete evidence. At that point, broad statements like “we support over-the-air updates” or “we monitor vulnerabilities” are no longer enough. Reviewers want to know what gets updated, who can push updates, how authenticity and integrity are verified, which components are tracked, how issues are reported, and how long security support will last.
This is also where a structured readiness workflow becomes useful. Instead of reviewing requirements in disconnected spreadsheets, Cyberexpert gives manufacturers a shared workspace to scope applicability, run a structured self-assessment, and build a product-specific requirements and evidence view before launch pressure builds.
Secure Update Gaps That Create Launch Risk
Partial update coverage
A common EN 18031 gap is treating updates as a firmware-only topic. That leaves out the bootloader, mobile application, backend services, application programming interfaces, third-party software components, and supplier-managed modules that also shape the product’s security posture.
This matters because security maintenance only works when the full product system is visible. If the device firmware can be patched but the cloud service, mobile app, or embedded third-party package is outside the review, the update story is incomplete. That gap often appears late because each part may look manageable on its own, while the product-level picture is still missing.
Weak trust in the update path
Another common problem is having an update mechanism without a strong trust model behind it. Close to launch, manufacturers should be able to explain how update authenticity is verified, how integrity is checked, how downgrade attempts are blocked, and what happens when an update fails.
This is where broad claims break down. “We can push updates remotely” does not answer the important questions. Can the product verify that the update came from a trusted source? Can it reject tampered packages? Is rollback protection in place? Is there a recovery path if installation is interrupted? Those are the details that matter in practice.
No defined support period
Security support is often treated as a commercial or customer-success topic that can be decided later. That creates a serious gap. Before launch, the support period should be clear enough to explain how long vulnerabilities will be monitored and remediated, and what customers can reasonably expect after release.
Without a defined support period, the maintenance story stays vague. That weakens both the customer-facing message and the compliance evidence behind post-launch security handling.
Feature changes mixed into late maintenance updates
Late in the release cycle, teams often bundle feature changes and security fixes into one package to stay on schedule. That can create problems. A small maintenance update is one thing. A change that materially affects intended use or compliance-relevant behavior is another.
Close to launch, update planning needs discipline. Security fixes should be clearly separated from feature changes wherever possible, and any substantial late-stage change should be reviewed for its compliance impact, not only for its engineering impact.
Extra care for products in EN 18031-3 context
Products that process virtual money or monetary value need especially careful review. Secure updates still matter, but the conformity route and the expectations around evidence become more sensitive. That means manufacturers in this category should avoid assuming that a standard software update story will automatically be enough.
Access Control Gaps That Are Easy to Miss
Weak password logic
One of the clearest launch-stage problems is weak credential setup. If password creation can be skipped, postponed indefinitely, or handled in a way that leaves the product effectively open, the risk is not only technical. It affects conformity logic too.
Good access control starts with a simple question, does the product require meaningful authentication where it should? If the answer is uncertain, or if convenience decisions weakened the setup flow, that needs attention before release.
Authentication at the front end, exposure at the back end
A product can look secure from the user side while staying too open somewhere else. An authenticated app does not solve the problem if a web admin page, local network service, service account, or another management interface remains exposed.
This is why access control should be reviewed across all interfaces, not just customer login screens. Security-relevant configuration changes should sit behind proper authentication and authorization, and unused interfaces should be disabled before release.
Debug and service paths left in place
Debug interfaces are another common blind spot. Development teams need them early. Production products should not carry that same openness into release. If a debug port, service shell, or internal command path remains accessible without strong protection, the product can look polished while still keeping a very practical route for misuse.
This is one of the reasons launch review should include a real interface inventory. It is much easier to close these issues before production than after a product is already on the market.
Broad privileges and weak role separation
Authentication alone is not enough. Privilege design matters too. A connected product may technically restrict access, while still giving overly broad permissions to backend roles, local services, or companion applications.
Before launch, manufacturers should be able to explain which identities exist, what each one can do, which actions are security-relevant, and what is blocked by default. Least-privilege thinking is often where access control matures from “someone needs to log in” to a structure that is actually defensible.
Parent or guardian control where relevant
Some product contexts require more than standard authentication logic. Where parent or guardian control is relevant, the access-control model needs to reflect that actual usage environment. This is not a cosmetic feature choice. It is part of whether the control model matches the product category and user context.
Vulnerability Handling Gaps That Weaken Readiness
No public disclosure process
A support email address is not the same as a vulnerability disclosure process. Close to launch, there should be a clear and public route for reporting security issues, plus defined expectations for acknowledgment and follow-up.
This is one of the easiest places to look prepared without actually being prepared. If researchers, customers, or partners do not know how to report issues, or if internal teams do not know who owns the response, the process is still immature.
No clear ownership after a report comes in
Intake is only the beginning. Someone needs to assess severity, coordinate remediation, decide on communication, and drive closure. Without ownership, reported vulnerabilities often end up sitting between engineering, product, support, and compliance.
A mature process should make those handoffs clear. Before launch, manufacturers should know who receives reports, who triages them, who signs off on remediation, and how decisions are documented.
No software component visibility
Third-party packages, supplier modules, open source libraries, and cloud dependencies are often scattered across teams and vendors. If there is no reliable inventory of these components, vulnerability handling becomes reactive and incomplete.
This is where a software bill of materials, or at least a disciplined component inventory, becomes valuable. It gives the team a starting point for monitoring exposure, deciding what is affected, and proving that the release candidate was reviewed properly.
No evidence trail
A strong process leaves evidence behind. That means there should be a link between the published policy, the reported issue, the triage decision, the remediation action, the release handling, and the support commitment.
Without that trail, even good work becomes hard to demonstrate. In practice, this is one of the biggest differences between a security-aware team and a launch-ready team.
What to Review Before Release
Before the launch is frozen, manufacturers should pressure-test five questions.
Does the update model cover the whole product system, including device, app, backend, and third-party components?
Can the team explain how update authenticity, integrity, rollback resistance, and recovery are handled?
Does access control extend across all interfaces, including admin paths, local services, and debug mechanisms?
Is there a public vulnerability disclosure route, with clear ownership and a defined internal response flow behind it?
Is the evidence package strong enough to show how updates, authentication decisions, component visibility, and vulnerability handling actually work in practice?
These questions are useful because they shift the review away from general statements and toward concrete implementation and evidence.
Common EN 18031 gaps before launch rarely come from one dramatic flaw. They usually appear where product decisions, documentation, and launch timing meet, which is exactly why they are so often missed until late in the process. They usually come from incomplete update coverage, weak access-control decisions, exposed interfaces, undefined support commitments, and vulnerability handling that exists informally rather than operationally.
Those issues are far easier to fix before release than after the product is already under launch pressure. A good pre-launch review should look at the product as one system, device, companion software, backend services, interfaces, maintenance model, and evidence together.
That approach gives manufacturers a much clearer view of where the real gaps are, what needs to be tightened before release, and where expert review may be worth bringing in before small weaknesses turn into larger delays.
Related Articles
