title: CRA Article 14 Operator Reporting Runbook owner: Operations + Notify platform status: Draft last_verified_against_enisa_srp_guidance: 2026-04-30 verification_scope: Local repository guidance/code only; no external web fetch. legal_notice: Local/offline operational guidance only; not legal advice.

CRA Article 14 Operator Reporting Runbook

This runbook is for Stella operators preparing Cyber Resilience Act Article 14 early warnings, vulnerability notifications, and final reports through the local Notify ENISA CRA channel. It is based on local repository docs and code verified on 2026-04-30. No external web fetch was used during this verification, and this document is not legal advice.

The default Stella posture is operator-controlled: produce the report, sign it, drop the handoff package on an operator-owned filesystem, verify it offline, and let the reporting party decide how to submit it. Auto-submit is opt-in only and is not live HTTP submission in the current ENISA connector slice.

Responsibility Boundary

Use this boundary before opening a CRA timeline:

Do not put Stella’s manufacturer identity into reporter fields for a customer product unless the customer has explicitly delegated that role and counsel has approved the wording.

Roles

Timeline

CRA Article 14 reporting uses the shared Notify incident-report timeline. The CRA countdown starts when an incident is classified as CRA-reportable by the cra.incident.classified ledger event or, while the Findings ledger event emission is blocked, by the Incident Commander’s recorded classification time.

The timeline emits a SEV-1 evaluation alert when the active milestone reaches 75 percent elapsed or misses its deadline. A late transmission is rejected unless an override is supplied with actor, reason, timestamp, and ticket reference.

Open The Incident

1. Assign the Incident Commander, Reporting Owner, Notify Operator, Evidence Custodian, Authority/Security Admin, and Legal/Compliance Reviewer.
2. Decide the reporting locus: Stella-as-manufacturer or customer-as- manufacturer. Record this in the incident ticket.
3. Record classifiedAt in UTC and the evidence that made the incident CRA-reportable, such as active exploitation, affected product/version, severity, and reachability/VEX facts.
4. Activate Authority incident access for operators who need elevated incident actions. Tokens must include obs:incident and an incident_reason.
5. Create or update the CRA timeline. Until Findings-owned event emission lands, keep the ticket’s classification record and evidence bundle as the source of truth for the countdown.

Enable Evidence Locker Incident Mode

Enable Evidence Locker incident mode before report generation so all new evidence bundles receive incident metadata and extended retention:

{
  "EvidenceLocker": {
    "Incident": {
      "Enabled": true,
      "RetentionExtensionDays": 60,
      "CaptureRequestSnapshot": true
    }
  }
}

When incident mode is active, newly sealed bundles receive:

• incident.mode, incident.changedAt, and incident.retentionExtensionDays manifest metadata.
• incident/request-*.json debug artifacts when request snapshot capture is enabled.
• Timeline/notifier signals for activation and deactivation.
• Extended ExpiresAt based on RetentionExtensionDays.

Create legal holds for report-critical bundles when counsel, a regulator, or customer policy requires retention beyond the incident extension. Do not shorten retention while any CRA report milestone, regulator inquiry, or customer dispute is open.

Configure The ENISA CRA Channel

Default filesystem handoff:

{
  "name": "enisa-cra",
  "type": "Custom",
  "purpose": "enisa-cra",
  "target": "/var/lib/stellaops/handoff/enisa",
  "secretRef": "authority://secrets/notify/enisa"
}

Run channel health and a test preview before using it for a live incident. The test preview must show:

• contract version enisa-incident-reporting.v1
• local envelope schema enisa-incident-reporting-local-envelope-v1
• delivery mode operator-filesystem
• enisaSrpSchemaValidation.status = blocked

The blocked SRP status is expected until an official ENISA SRP schema package is vendored locally, version-pinned, and license-reviewed. The connector must not fetch official schemas at runtime.

Prepare And Send The 24h Early Warning

Goal: submit a first warning within 24 hours of CRA classification, using known facts without waiting for complete root cause.

1. Confirm classifiedAt, reporter legal entity, contact ref, product id, product version, affected deployment, and incident id.
2. Attach exploitation evidence and the first immutable Evidence Locker bundle.
3. Build the early_warning_24h envelope with the timeline due timestamps.
4. Obtain operator approval and record operatorApprovalRef in the report.
5. Sign the envelope through the SignerPipeline adapter.
6. Verify the DSSE envelope and manifest locally before any external handoff.
7. Record the envelope hash, DSSE hash, delivery-ledger event, audit event, and Evidence Locker bundle ref in the incident ticket.
8. Advance the CRA timeline to EARLY_WARNING_SENT.

Prepare And Send The 72h Vulnerability Notification

Goal: submit the structured vulnerability notification within 72 hours of CRA classification.

1. Revalidate affected versions, vulnerability refs, exploitation status, mitigations, and customer/operator impact facts.
2. Include at least one vulnerability reference and one mitigation.
3. Attach updated attestations, evidence refs, and the 24h transmission hash.
4. Obtain fresh operator approval. The approval ref must be linked to the incident ticket and retained with the handoff package.
5. Sign and verify the vulnerability_notification_72h package.
6. Record the envelope hash, DSSE hash, delivery-ledger event, audit event, and Evidence Locker bundle ref.
7. Advance the CRA timeline to NOTIFICATION_SENT.

Prepare And Send The 14d Final Report

Goal: submit final facts within 14 days of CRA classification.

1. Confirm closure status, root cause, remediation summary, fixed versions, remaining customer action, and residual risk.
2. Include the earlier transmission hashes: early_warning_payload_hash and vulnerability_notification_payload_hash.
3. Include final report bundle refs, remediation evidence, and operator approval.
4. Sign and verify the final_report_14d package.
5. Record the envelope hash, DSSE hash, delivery-ledger event, audit event, and Evidence Locker bundle ref.
6. Advance the CRA timeline to FINAL_REPORT_SENT, then close the timeline after the Incident Commander confirms no further report is due.

Approval, Fresh-Auth, And Auto-Submit

Filesystem handoff is the default. Even in filesystem mode, every report package must carry an operator approval reference because the report represents a regulator-facing statement.

Auto-submit planning is stricter:

{
  "properties": {
    "notify.channel.enisa.autoSubmit": "true",
    "notify.channel.enisa.srpEndpoint": "https://tenant-configured-srp.example/report",
    "notify.channel.enisa.tenantApproverRef": "approval://tenant-a/enisa/incident-cra-001",
    "notify.channel.enisa.freshAuthRef": "authn://tenant-a/session/fresh-001"
  }
}

Policy for use:

• Auto-submit must be tenant opt-in, per channel.
• The approver must be authorized for the tenant and reporting channel.
• Fresh-auth must represent an interactive authentication within 5 minutes of the approval/submission action.
• Incident actions should use obs:incident scope and capture incident_reason.
• Missing srpEndpoint, tenantApproverRef, or freshAuthRef makes the connector fail closed.

Current implementation limit: the ENISA connector records enisa.auto_submit.requested when auto-submit fields are present, but live SRP HTTP submission is not implemented in this slice. Treat the audit event as a planned submission request, not proof that ENISA received the report.

Overrides And Break-Glass

Use a timeline override only when the report must be sent after a deadline or when upstream evidence is delayed. The override record must include:

• actor
• reason
• UTC timestamp
• ticket or approval reference
• affected milestone
• evidence of Legal/Compliance review where available

Do not edit the original classifiedAt timestamp to make a deadline appear met. Record the actual send time and the override reason.

Use break-glass only when normal Authority authentication is unavailable. Follow the Break-Glass Account Runbook, use the security_incident or deployment-approved reason code, keep the session time-limited, and attach the break-glass audit events to the incident evidence pack. Break-glass is not a substitute for operator approval when normal auth is available.

Evidence Retention Checklist

For each milestone, retain:

• local ENISA envelope JSON
• DSSE envelope JSON
• handoff manifest.json
• Notify delivery-ledger event
• Notify audit event
• operator approval record
• fresh-auth hash/ref when auto-submit is requested
• timeline state and replay hash where available
• Evidence Locker bundle id, root hash, signature, and incident metadata
• legal hold id when one is created
• any override or break-glass audit events
• offline transfer manifest and chain-of-custody record for air-gapped sites

Store these refs in the incident ticket and the Evidence Locker bundle metadata. Final reports must include hashes of the earlier transmissions so replay can prove the sequence.

Offline And Air-Gapped Operation

The CRA reporting path is designed to operate without external network access:

• Notify uses deterministic local envelope validation.
• The connector does not fetch ENISA SRP schemas or portal metadata.
• The handoff package is written to an operator-controlled filesystem path.
• DSSE verification uses local trust roots and offline verifier tooling.
• Air-gapped operators transfer the signed handoff package through their approved media process and record chain of custody.

If the official SRP portal or national workflow is unavailable from the Stella environment, export the verified package and submit through the Reporting Owner’s approved connected environment. Record the submission receipt or manual submission evidence back into Evidence Locker when it becomes available.

Current Blockers

These are known as of 2026-04-30:

Closeout

Before deactivating incident mode:

1. Verify all required milestones are sent or explicitly closed as not applicable by the Reporting Owner.
2. Verify the final report contains prior transmission hashes.
3. Confirm Evidence Locker bundles are sealed, signed, and retained.
4. Confirm legal holds are applied where required.
5. Export a portable evidence pack for the Reporting Owner.
6. Record the closeout decision, remaining blockers, and post-incident actions.
7. Disable Evidence Locker incident mode only after the Incident Commander and Evidence Custodian agree that forensic capture can return to normal.

References

• ENISA Incident Reporting contract (v1)
• Notify ENISA channel
• Notify architecture
• Evidence Locker incident mode
• Break-Glass Account Runbook
• Air-Gap Operations Runbook