Post-market Surveillance (PMS) is the systematic process by which a manufacturer actively monitors the performance and safety of their products after they have been placed on the EU market. PMS is a legal obligation under virtually all CE marking directives, not an optional quality improvement activity. The EU Cyber Resilience Act (CRA) has raised the bar significantly — transforming PMS from a passive complaint-collection function into an active, continuous cybersecurity monitoring programme.
Legal Basis
Post-market surveillance obligations arise from:
- The General Product Safety Regulation (GPSR, EU 2023/988) — applies to all consumer products; manufacturers must collect and analyse field information, investigate incidents, and take corrective actions
- Sector-specific directives — EMC, LVD, RED, and Machinery all require manufacturers to monitor field reports and investigate safety-relevant issues
- Medical Device Regulation (EU 2017/745) — the most prescriptive PMS regime; requires a formal PMS plan, PMS reports (PSUR for Class IIa+), field signal analysis, and periodic safety update reports
- EU Cyber Resilience Act (EU 2024/2847) — requires continuous vulnerability monitoring for the product’s entire supported lifetime (minimum 5 years), 24-hour ENISA notification of actively exploited vulnerabilities, and monthly updates on remediation status
CRA Post-market Obligations in Detail
The CRA’s post-market requirements are the most operationally demanding in EU hardware law:
| Obligation | Timeline | Who must act |
|---|---|---|
| Report actively exploited vulnerability | Within 24 hours of becoming aware | Manufacturer → ENISA (via ENISA’s single reporting platform) |
| Preliminary notification | Within 72 hours of discovering the vulnerability was actively exploited | Manufacturer → ENISA |
| Final vulnerability report | Within 14 days of implementing a fix | Manufacturer → ENISA |
| SBOM maintenance | Continuous — must reflect all software components at any point in time | Manufacturer |
| Vulnerability handling policy | Must be published and maintained | Manufacturer |
| Security updates | Must be provided free of charge for the supported lifetime | Manufacturer → Users |
| End-of-security-support notification | Must notify users and EU database when support ends | Manufacturer |
PMS Infrastructure for Hardware Products
Effective post-market surveillance for connected hardware requires:
1. Software Bill of Materials (SBOM) Monitoring The SBOM must be cross-referenced continuously against public vulnerability databases (CVE/NVD, OSV.dev, GitHub Advisory Database, vendor security advisories). When a CVE affects a component in the SBOM, the impact on the specific product configuration must be assessed.
2. Vulnerability Assessment and Triage Not every CVE in a dependency is exploitable in a specific product configuration. A proprietary library compiled with specific flags, running in a sandboxed environment, may not be affected by a vulnerability described in the CVE. Triage requires product-specific expertise — generic CVE scanners produce false positives that lack this context.
3. OTA Update Infrastructure Security patches must reach deployed devices reliably. This requires authenticated OTA infrastructure (SUIT manifest-based firmware updates, or equivalent), a staging/rollback mechanism, and telemetry confirming update uptake across the installed base.
4. Incident Response Process A documented process for receiving, triaging, and responding to externally reported vulnerabilities (coordinated vulnerability disclosure) must exist and be publicly referenced in the product documentation.
5. ENISA Reporting Process The 24-hour reporting requirement is operationally demanding. Automated alerting from SBOM monitoring tools feeding into a defined escalation path is required — a manual daily review is insufficient for compliance.
PMS vs. Quality Management
Post-market surveillance is distinct from, but feeds into, quality management:
| PMS | Quality Management (QMS) | |
|---|---|---|
| Scope | Field performance of specific products | Processes and systems producing those products |
| Regulatory basis | Product directives | ISO 9001, ISO 13485 (MDR), IEC 62443 (CRA) |
| Trigger | Market data, field incidents, vulnerability disclosures | Nonconformances, audits, management review |
| Output | Corrective actions, ENISA notifications, safety alerts | CAPA, process improvements, supplier evaluations |