Wir rufen die Plattformseiten der ENISA nach Zeitplan ab und vergleichen ihren Text mit der letzten Kopie. Eine Änderung veranlasst uns, Feldsatz, öffentliche Referenz und Formularhilfe zu prüfen, bevor ein Kunde darauf trifft.

Überwachte Seiten

• ENISA SRP topic page · 200 11 Änderung(en)
• ENISA SRP FAQ · 200 11 Änderung(en)
• SRP portal landing · 200 1 Änderung(en)
• ENISA SRP glossary · 200
• ENISA SRP AR user manual · 200

ENISA published glossary v1.6 and AR user manual v1.2 on 21 October 2026 for platform version 1.2.1. Row v26, 'Date and time when you become aware of the Actively Exploited Vulnerability', is now mandatory on the early warning; the 'next release' footnote is gone. Row i37 is renamed 'Date and time when you become aware of the incident'. New row 7a, free-text 'Additional Information' about the manufacturer, optional on the early warning. Rows 1 to 14, the CVE and EUVD IDs (v19, v20), and on later steps rows 15 and 18 and the 72-hour narratives (v21, i32, i39) are marked N/A after the step that asks them, instead of 'copied from previous step'. v26a is 'by default copied from previous step' at 72 hours (required in v1.5); i38 is optional at 72 hours (required in v1.5). v30 'Please provide further information' is optional only under PEC activation, and the PEC delay reason has three grounds, adding exploitation confined to the coordinating CSIRT's Member State. The manual: a Primary AR with a Verified association invites from Settings > 'Invite Backup', any user already registered on the SRP can be invited, the invitee accepts from Alerts within 7 days and appears as 'AR Backup User'. FAQ Q26 (15 October) is unchanged: the 72-hour counter still runs 48 hours from the early warning.

In ExploitClock: Drafts mirror v1.6 row by row: the awareness instant is a platform field on both tracks under the new labels, each step lists only its own rows, 7a is added, v30 belongs to PEC. The form-filler, the .txt fill sheet, the public field reference, the CRA explainer, the deadline check, Help and the free drill were updated the same day, as were the Secondary AR hint and the onboarding deputy step. The case page keeps both clocks until ENISA says the counter runs from awareness. Our page watch now also covers the glossary and the manual.

ENISA's platform page: 'On the 20 October 2026 the CRA SRP has been upgraded to version 1.2' and 'the way of inviting the Secondary Assigned Representatives significantly differs now'; 'for a short period the Platform will also support the old way', and the documentation is being updated. ENISA has not yet published the new steps. ENISA later revised the page to read 'On 20 October 2026, the CRA SRP was upgraded to version 1.2.1', and published the new invitation steps on 21 October (see that entry). Glossary v1.5 and the FAQ of 15 October are unchanged, so the notification fields stay as they were.

In ExploitClock: The readiness checklist and the onboarding deputy step now say the invitation process changed on 20 October and point you to the platform's invite screen, instead of stating the old CSIRT-verification route as the only one. No draft field changed. We will update the steps when ENISA publishes its revised guides.

ENISA upgraded the Single Reporting Platform to version 1.1 on 12 October 2026 and published glossary v1.5 on 15 October. Against v1.3, which our drafts mirrored, v1.5 adds row v26a 'Date and time when the Actively Exploited Vulnerability occurred (UTC time)': optional on the early warning, required on the 72-hour notification, carried forward to the final report. It also adds a free-text 'AR Note' (row 40) on every stage and a 'CSIRT Note' (row 41) that the coordinating CSIRT writes. Every other row keeps its required/optional status. Row v26, when you became aware, is still footnoted 'available in the next release', and FAQ Q26 is unchanged: the 72-hour counter still runs 48 hours from the early warning. The FAQ (dated 15 October) adds Q34: you cannot withdraw a notification submitted by mistake; only your coordinating CSIRT can close it, on request by its contact details or by a note on the submission. It also adds Q35: under Art. 17(5) ENISA may contact the manufacturer to agree when a notified, publicly known vulnerability goes into the EUVD, and can help assign a CVE ID as a CVE Numbering Authority. Q24 now says the platform is English-only and the factsheet is being translated.

In ExploitClock: Vulnerability drafts have the v26a field and flag it as missing on the 72-hour notification until you fill it; we do not guess it. Every draft has the AR Note. The form-filler knows both labels, and the public field reference shows glossary v1.5. The awareness field stays marked 'not on SRP' on the vulnerability track, and the case page keeps both clocks.

FAQ Q9 (page dated 30 September 2026): Primary and Secondary Assigned Representatives associated with the same manufacturer can access, view and update that manufacturer's notifications regardless of which AR submitted them, so another AR can continue the reporting process through later stages. The only exception is draft notifications, which are stored in the individual AR's account and are invisible to other ARs. New Q32: a mis-typed manufacturer name is fixed by registering again under the correct name; associations are removed under Settings > Association Management once the manufacturer is Verified, or by asking the coordinating CSIRT to reject them (AR User Manual section 4.5). New Q33: a rejected AR association is decided by the CSIRT designated as coordinator, not ENISA. Q26 is unchanged: the 72-hour counter still shows a due time 48 hours after the early warning, and ENISA states a future release will calculate it from the 'Date/Time when you became aware' field for both vulnerabilities and incidents. The page publishes the helpdesk address cra-srp-helpdesk@enisa.europa.eu.

In ExploitClock: The onboarding deputy step no longer says a Secondary AR sees only their own notifications; it says cover works, and that a parked draft is the one thing a deputy cannot see. The two-clock display on every case stays until ENISA ships the awareness-based counter.

Manufacturers must report actively exploited vulnerabilities and severe incidents via the single reporting platform. Applies to products placed on the market before 11 Dec 2027 as well (Art. 69(3)).

In ExploitClock: ExploitClock clocks, drafts and evidence trail are live for this date.

The platform went live at portal.cra-srp.enisa.europa.eu on the day Article 14 started applying, with the AR user manual and terms published the day before. Three things the Regulation anticipates did not ship with it: a reporting API, voluntary reporting under Art. 15, and — on the actively-exploited-vulnerability form — the field recording when the manufacturer became aware (glossary v1.3 of 10 Sep 2026, row v26: 'available in the next release'). The severe-incident form has the field under the label 'Date and time when the incident was detected (UTC time)' (row i37). FAQ Q26: 'In the current release, the 72-hour counter displays a due date/time 48hrs after submission of the 24-hour Early Warning', so a notification may show as overdue before 72 hours from awareness have elapsed; a later release will count from the awareness field.

In ExploitClock: Awareness is marked 'not on SRP' in vulnerability drafts, on the public field reference and in the .txt an Assigned Representative works from, and pre-filled under the platform's own label in incident drafts. The case page shows the platform's counter (early warning + 48h) next to the legal deadline; the free deadline check shows the gap in either direction. Draft field set re-aligned to glossary v1.3.

The Single Reporting Platform will be available at portal.cra-srp.enisa.europa.eu. EU Login + MFA; Assigned Representative roles (1 primary, up to 20 secondary); up to 20 notifications before AR validation. No API at initial release. Voluntary reporting (Art. 15) not available at launch.

In ExploitClock: Drafts link to the portal; Settings has an SRP readiness checklist; the SRP form-filler bookmarklet targets the portal's field labels.

Field-by-field specification of the notification form: 18 common fields, 11 for actively exploited vulnerabilities, 9 for severe incidents, with character limits and required/optional status per stage.

In ExploitClock: SRP_FIELDS in app/domain/drafts.py mirrors this glossary. Every draft validates against it.

One coordinating CSIRT per Member State published (e.g. BSI/CERT-Bund, CERT-FR, NCSC-NL, CCB, NCSC-IE, INCIBE-CERT).

In ExploitClock: EU_MEMBER_STATES map in drafts pre-fills the coordinating CSIRT from the main-establishment state.

Trigger, three stages, coordinating CSIRT role, offline fallback (email to a CSIRT is not a formal notification), legacy products.

In ExploitClock: Settings records a direct CSIRT fallback contact; drafts note that email alone does not constitute notification.

§213: awareness = a reasonable degree of certainty, after an initial assessment, that a vulnerability is actively exploited (or a severe incident occurred). §214: the assessment must be prompt. §217: no retroactive reporting for exploitation known before 11 Sep 2026. §§219–221: informing users is risk-based and proportionate.

In ExploitClock: Cases open in an 'assessment' state at detection; the legal clock starts at confirmed awareness; detection and awareness timestamps are recorded separately; a 4-hour assessment target is timed and alerted.

The coordinating CSIRT may delay dissemination where a mitigation is expected within 72 hours, where the information would enable exploit development, or during a CVD process (Art. 3); also during SRP compromise (Art. 5).

In ExploitClock: The 'Mitigating measure expected shortly' field and the 72h-stage PEC toggle are surfaced with this basis in the draft help text.

Defines the Annex III/IV product categories.

In ExploitClock: Product classification field (default / important I / important II / critical) feeds the SRP 'Product type' and 'Product class' fields.

Art. 14 defines the 24h / 72h / 14-day (vulnerability) and 24h / 72h / 1-month (incident) cadence; Art. 3(42) defines 'actively exploited'; Art. 64 sets fines up to €15M / 2.5% for Art. 13–14 breaches, with micro/small enterprises exempt from fines for missing the 24h early warning (Art. 64(10)).

In ExploitClock: Deadline offsets in app/domain/timers.py; definitions quoted in the product and marketing copy.