The risk created by products already placed on the market and still operating in customer environments. Under the CRA, those units can remain subject to reporting duties and enforcement even when the product was shipped long before the main compliance date.
What Installed Base Exposure Means
Installed base exposure is the security and compliance risk that remains after a product has already been shipped and is still running in customer environments. For CRA-scoped products, the exposure can persist long after release because fielded units may still trigger reporting duties, remediation pressure, or enforcement attention.
Why Installed Base Exposure Is Hard to Eliminate
The challenge is that product risk does not end at launch. Older deployments may sit outside the current engineering team’s direct control, yet they can still inherit defects, weak configurations, or unsupported dependencies that matter to regulators and customers alike. In practice, the installed base becomes part of the product’s live security surface.
That makes post-release visibility essential. Teams need to know where products were sold, how they were deployed, which versions remain active, and whether any customer environments are still reachable or materially exposed. Without that inventory, exposure is easy to underestimate.
How Installed Base Exposure Changes the Security Picture
This term matters because it shifts attention from “what was shipped” to “what is still operating.” A vulnerability, unsafe default, or reporting obligation can remain live in the market even after the main compliance milestone has passed, so the organisation’s obligation is not limited to the original launch window.
It also changes the way remediation is judged. A fix that is straightforward for newly sold units may be slow or impractical for older environments, especially when customers control maintenance windows, integration dependencies, or on-premises upgrade paths. The installed base therefore becomes a long-tail risk domain, not a one-time release issue.
Exposure Signals and Control Points
Practitioners usually look for three things: whether the product is still present in customer environments, whether any fielded instances are internet-reachable or otherwise exposed, and whether vendor advisories or regulator notices indicate continuing obligations. Public vulnerability notices and product notices help establish whether exposure is still active, but the organisation still needs its own asset and customer-deployment picture.
- Maintain an accurate inventory of shipped versions, customer deployments, and support status.
- Correlate product notices with real-world deployment data so old installs are not forgotten.
- Track compensating controls where a patch or upgrade cannot be applied immediately.
For broader detection and prioritisation, teams can use vulnerability intelligence and exposure tracking to confirm whether fielded systems are still at risk, then map that back to support, notice, and remediation workflows.
Risk and Threat Considerations
Installed base exposure creates a durable attack and compliance surface because vulnerable or noncompliant units may continue to exist in customer environments after the vendor believes the release cycle is complete. Attackers often target the long tail of older deployments because they are slower to patch, harder to inventory, and more likely to have inconsistent controls.
Failure mechanism: The organisation loses visibility or control over deployed units, so a defect, unsafe configuration, or reporting obligation continues to exist in the field even when internal release management has moved on.
Impact: Exploitation, regulatory pressure, customer trust damage, and prolonged remediation effort can all persist across the installed base, especially where fielded systems are widely distributed or only partially managed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 sets the technical controls, while EU Cyber Resilience Act defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU Cyber Resilience Act | Regulatory obligations for product security and lifecycle risk | Installed base exposure directly reflects continuing obligations for shipped products in customer environments. |
| Recommendation — Track fielded products and maintain reporting and remediation processes for deployed units that remain in service. | ||
| NIST CSF 2.0 | ID.AM-01 — Asset Inventory | Installed base exposure depends on knowing what products are deployed and still operating. |
| GV.SC-01 — Cyber Supply Chain Risk Management Strategy | Fielded product exposure is a supply-chain and lifecycle governance problem across shipped units. | |
| PR.DS-10 — Integrity of Information and Systems | Old deployments may retain insecure or altered states that affect product integrity in the field. | |
| Recommendation — Maintain an accurate inventory of shipped and customer-deployed assets so lingering exposure can be identified. Define ownership for post-sale product risk and connect fielded exposure to supply-chain governance processes. Monitor fielded deployments for integrity drift and remediate affected customer instances. | ||
Practitioner Guidance
Governance implication: Treat installed base exposure as a lifecycle obligation, not just a product-quality issue. The practical question is who owns the fielded estate, who tracks affected customers, and who can prove that remediation or notice obligations were met across the entire deployed population.
Practitioner takeaway: The strongest control is usually not a single patch event, but a repeatable process for knowing what is still out there, what it is exposed to, and which obligations survive after shipment.