After an SBOM match confirms an affected product, notify customers in order of exposure and ability to act: those running affected, internet facing deployments first, then other affected customers, then those who ask. Tell unaffected customers only if they are likely to hear about the issue elsewhere and wonder.
Why order matters
A single mass email to everyone sounds fair, but it buries the people who need to act under people who do not. It also puts a spike on your support queue at the worst moment. Tiering gets the right message to the right group first, and it is easier to defend afterwards.
A four tier model
| Tier | Who | Message | When |
|---|---|---|---|
| 1 | Customers running an affected release, reachable from the internet, or with a known exploit in play | Direct, specific, with a mitigation | First |
| 2 | Customers on an affected release without those factors | Direct, with fix or upgrade path | Same day as the fix, or sooner |
| 3 | Customers on unaffected releases who have a stated interest | Short "not affected" note, link to VEX | After tier 1 and 2 |
| 4 | Everyone else | Public advisory only | On publication |
Adjust the tiers to your product. A hosted service you patch yourself needs fewer tier 1 messages than software customers run.
Steps
- Take the affected release list from your component index.
- Join it to your customer record of who runs which release. If you do not know, say so, and use a public notice.
- Mark deployment exposure where you can: public endpoint, internal only, or air gapped.
- Build the tier lists and check them against known exploitation.
- Draft one template per tier, plain and short.
- Send tier 1, wait for replies, then tier 2.
- Log who was told, when and how, for audit.
What each message must contain
- The product and versions affected.
- What the issue allows an attacker to do.
- What the customer should do now, and by when.
- Where the advisory and VEX are published.
- A named contact and a channel for questions.
Leave out speculation. If the investigation is open, say so and give the next update time.
The regulatory angle
The EU Cyber Resilience Act's Article 14 asks manufacturers to inform affected users of an actively exploited vulnerability, and of the measures they can deploy, where appropriate in a structured, machine readable format. Where the manufacturer does not do so in a timely way, the coordinating CSIRTs may inform users. Whether it applies to your product is a legal question, but the instinct, tell the people who can act, is sound everywhere.
Quick check
Should we notify customers who are not affected?
Usually a public advisory is enough. Send a direct note only to customers who asked, or who are likely to see the news and worry.
What if we do not know who runs which release?
Publish prominently, notify everyone with a short message, and add a way for customers to confirm their version.
Safeguard's SBOM and dependency scanning and asset discovery can supply the release and inventory data this model depends on. A free scan is available. See also customer asks: were we affected.
Sources
- Regulation (EU) 2024/2847, EUR-Lex, Article 14
Last reviewed: 19 October 2026.
