For a hosted service the vendor patches, so the advisory tells customers what was fixed and whether they need to act on their side, such as rotating credentials. For software customers run themselves, the customer patches, so the advisory must give versions, an upgrade path and a deadline for acting. Hybrid products need both messages.
Why the model changes the message
The same flaw in the same library creates different duties depending on who operates the product. If you run the service, you control the fix and its timing. If customers run it, you control only the release and the message. Mixing the two up leads to either alarm over nothing or silence when action is needed.
Comparison
| Deployment | Who patches | Advisory emphasis | Typical customer action |
|---|---|---|---|
| Hosted by vendor | Vendor | What was affected, when it was fixed, whether data was exposed | Rotate secrets or review logs if told to |
| Self hosted by customer | Customer | Affected versions, fixed version, upgrade steps | Upgrade or apply the workaround |
| Hybrid, with agents or connectors | Both | Which part is affected, in which place | Update the local part, confirm the hosted part |
| Embedded in a device | Vendor builds, customer installs | Firmware version, update method, support end date | Install the update |
Steps for a hosted product
- Find the affected components using your service SBOM.
- Patch and verify in production.
- Check logs for signs of abuse during the exposure window.
- Decide whether customers need to act, such as rotating tokens.
- Publish a dated notice. Say what was exposed and for how long.
- If personal data may be involved, bring in your privacy and legal teams. That is a separate assessment with its own deadlines.
Related: notify customers if a bad package never ran in production.
Steps for a self hosted product
- Match the component across all supported releases. See which supported versions are affected.
- Ship the fixed release or a patch, and a workaround.
- Publish affected and fixed versions, and a VEX record.
- Notify exposed customers first.
- Track adoption if you can, and follow up on the slowest.
Pitfalls
- Publishing a version based advisory for a hosted product. Customers have no version to check.
- Saying "no action required" without saying why.
- Forgetting the customer run agent in an otherwise hosted product.
- Describing an unpatched device flaw with no support end date.
What the regulation says about timing
The EU Cyber Resilience Act applies to products with digital elements and has its own treatment of remote data processing solutions that are part of such a product. Check the scope for your offering. For software customers run, Annex I Part II asks that security updates be disseminated without delay with advisory messages describing potential action.
Quick check
If we patched a hosted service before disclosure, must we tell customers?
It depends on whether customers must act and on contracts and law. At minimum, a dated public note is good practice. Ask counsel if data may have been exposed.
Do hosted products need a VEX?
Customers may still ask whether a flaw in a library affected the service. A short statement with a date answers that.
Safeguard's SBOM and dependency scanning and asset discovery can inventory hosted and self hosted software alike. A free scan is available.
Sources
- Regulation (EU) 2024/2847, EUR-Lex, Annex I Part II
Last reviewed: 19 October 2026.
