The Conventional Wisdom
When regulators announce a new reporting deadline, many security teams react by building a notification process. You draft a template, map out who contacts whom, and create a decision tree for what counts as "severe." You might even run a tabletop exercise where everyone practices their lines.
The common belief is that if you can report an exploited vulnerability within 24 hours of awareness, you're compliant. Check the box, move on.
The Real Challenge
That approach misses the actual challenge. The EU's new requirement for digital product manufacturers isn't about filling out a form quickly. It's about knowing what's happening in your products from the start.
The hard part isn't the reporting. It's the awareness.
Most manufacturers discover vulnerabilities weeks or months after exploitation begins. By the time your security team realizes something is wrong, the 24-hour window has already closed. You're building a notification system for an alarm you can't hear.
Here's what makes this requirement different: it applies to all exploited vulnerabilities and severe incidents across every sector producing digital products. That baby monitor, fitness tracker, or industrial sensor. If it has a digital component and you sell it in the EU, the clock starts ticking the moment you become aware of a problem.
The real question isn't "Can we report within 24 hours?" It's "How will we know within 24 hours?"
Understanding Awareness
The requirement states that manufacturers must report within 24 hours of becoming aware. Not 24 hours after the incident occurs or a customer complains. Twenty-four hours after you know.
This shifts the compliance burden backward. You can't wait for your annual security audit to surface problems. You can't rely on customers to tell you something is wrong. You need detection systems that surface exploitation patterns as they emerge.
Consider what "awareness" means in practice. If your security monitoring system flags unusual authentication attempts on Tuesday morning, you're aware. If a researcher emails your security team about a vulnerability they found, you're aware. If your customer service team notices a pattern of complaints suggesting a security problem, you're aware.
The regulation doesn't give you time to investigate whether the flag is real, convene a meeting to discuss severity, or wait for legal to review the language. Awareness triggers the clock.
What to Do Instead
Start with detection, not notification. Your first investment should be in systems that can identify exploitation patterns in near-real-time. This means:
Build continuous monitoring into your products. If you manufacture connected devices, you need telemetry that shows you when authentication patterns change, when firmware is modified unexpectedly, or when devices start communicating with unusual endpoints. For software products, instrument your applications to surface anomalous behavior.
Create a single intake point for security signals. Right now, vulnerability information probably flows through multiple channels: your security team, customer support, external researchers, social media monitoring. You need one place where all these signals converge and get evaluated against the same criteria. This isn't about creating bureaucracy. It's about ensuring someone is actually watching.
Define "awareness" explicitly. Write down the specific conditions that constitute awareness for your organization. Is it when your monitoring system generates an alert? When a human reviews that alert? When you confirm the alert is accurate? The regulation doesn't specify, so you need to. Then train everyone who might receive security information to recognize when they've crossed that threshold.
Simplify your severity assessment. You have 24 hours total, not 24 hours to decide if you need to report. Create a clear framework for what constitutes a "severe" incident. When in doubt, report. The cost of over-reporting is much lower than the cost of missing the deadline on something that later proves significant.
Test your detection, not just your notification. Most tabletop exercises focus on "We've discovered a breach, now what?" Run exercises that start earlier: "How would we discover this breach?" Simulate scenarios where exploitation is subtle or where signals are ambiguous.
When the Conventional Wisdom Is Right
None of this means you should ignore your notification process. Once you know about an incident, you do need to report it quickly and accurately. Having templates, clear roles, and practiced procedures matters.
The conventional approach is right when you already have strong detection capabilities. If you can reliably identify exploited vulnerabilities within hours of their occurrence, then yes, focus on streamlining your reporting workflow.
It's also right for manufacturers who produce simple, well-understood products with limited attack surfaces. If you make a digital thermometer with basic connectivity and well-established security controls, your detection challenge is more manageable. You can reasonably expect to know quickly when something goes wrong.
But for most manufacturers, especially those producing complex connected products or software platforms with multiple integration points, detection is the bottleneck. You can have the world's most efficient reporting process, but it won't help if you don't discover problems until they've been exploited for weeks.
The EU requirement forces an uncomfortable question: when do you really become aware of security incidents in your products? If the honest answer is "eventually," you're not building a compliance program. You're building a notification system for problems you'll discover too late to report on time.
Start with awareness. The reporting will follow.
