Customer notification portal

The customer directory (Customers page) knows who operates your machines — every recorded deployment names its customer, and Resilic groups them automatically. The notification portal turns that directory into a channel: for each customer you can issue a public portal link where their employees subscribe to security notifications for the machines they operate.

This is groundwork for the CRA Art. 14(8) duty to inform impacted users about vulnerabilities, incidents, and corrective measures. Subscriptions complement — they never replace — that duty: having zero subscribers changes nothing about your obligation, and Resilic only ever sends at your explicit action with a human-approved artifact behind it.

The portal link

From the Customers page, expand a customer and create the portal link:

• The URL is shown once — copy it and share it with your customer contact. Only the hash is stored, like every public token in Resilic.
• Rotate issues a new URL and kills the old one immediately; existing subscriptions survive the rotation.
• Revoke takes the page offline. Revoked and invalid links are indistinguishable (not found).

The portal page itself shows the customer’s machines (product, version, sites), a subscribe form, and the current subscribers with masked email addresses. It never shows vulnerability or incident content — it manages subscriptions, nothing else.

Double opt-in, one-click opt-out

Anyone with the portal link can enter an email address (and choose German or English), but the subscription only becomes active when the confirmation link in the resulting email is clicked — the link is single-use and valid for 7 days. Until then, nothing else is sent to that address.

Every email carries a one-click unsubscribe link that works without login. Unsubscribed addresses receive nothing and can re-subscribe through the portal (which restarts the double opt-in).

Data protection

Data is minimal by design: the subscriber row holds the email address, the chosen language, and the consent timestamps — nothing more. On the builder side you see your customers’ subscribers in clear (you are the controller of that relationship) and can delete a subscriber on request; deleting the row deletes the personal data.

Sending notifications

Both send paths are explicit actions with a human-approved artifact behind them — Resilic never auto-discloses anything:

• From a published advisory: an approved security advisory offers Notify subscribed customers. Resilic works out which customers operate an affected product version and emails their confirmed subscribers — per recipient, in the recipient’s language, with the advisory’s facts (CVE, affected and fixed versions, recommended action) and the one-click unsubscribe link. A draft advisory cannot be sent: it has reached no user.
• From the “users informed” step: when a reportable event’s Art. 14(8) step links a published advisory, you can tick Also notify subscribed customers via Resilic. The send happens as above, and the “how were users informed” record fills itself from the outcome.

Every attempt — sent or failed — leaves a row in the delivery log attached to the advisory or event: masked address, outcome, timestamp. The mask is deliberate: the Art. 14(8) evidence survives a subscriber’s later erasure without retaining the personal datum. Zero subscribers changes nothing about the duty itself — the manual path remains, and the record says how it was met.