cra-kit: correct Art. 14 reporting mechanics and Art. 18 (an AR is optional); remove ROADMAP.md

[sameehj]

Summary

Follow-up to #574. Corrects two things the CRA kit stated incorrectly — how an Art. 14 report is filed, and whether an Art. 18 authorised representative is mandatory — and removes cra-kit/ROADMAP.md.

1. Art. 14 reporting mechanic

The kit described reports as going "to ENISA" directly. Under Art. 14/16 a manufacturer files via the ENISA Single Reporting Platform (SRP) to the CSIRT designated as coordinator, with ENISA notified simultaneously; fixed vulnerabilities are then published to the EUVD (Art. 17(5)). Corrected across the shortlist, cheat sheet, glossary, slide outline, and SKILL.md.

• vulnerability-handling-process.md: adds a "how an Art. 14 report is filed (SRP → CSIRT + ENISA → EUVD)" section; adds the severe-incident track (Art. 14(3)–(4), one-month final report); updates the diagram, the reporting rows of the service-level table, and the references. No status or commitment change: the headline stays 🟡 and the on-call section stays 🟠.
• Glossary: new SRP / CSIRT / EUVD entries; the CSIRT entry spells out the full Art. 14(7) cascade (AR, then importer, then distributor, then the Member State with the most users).

2. Art. 18 — an authorised representative is optional

This is a legal-position correction and deserves the closest review. Art. 18(1) reads:

A manufacturer may, by a written mandate, appoint an authorised representative.

It is permissive. There is no duty to appoint one, including for a manufacturer established outside the Union. The kit stated the opposite in eight places, and in the customer-facing pages that was advice about an obligation that does not exist.

The indirect route does not apply either: Art. 66 CRA adds the CRA only to Annex I of Regulation (EU) 2019/1020, which is the market-surveillance list. It does not bring products with digital elements under Art. 4 of that Regulation, so there is no back-door requirement for an EU-established economic operator.

• eu-authorised-representative.md rewritten around the correct mechanism: what Art. 18(3) puts in a mandate, what Art. 18(2) keeps with the manufacturer (Art. 13(1)–(11), (12) first subpara, (14) cannot be delegated), and how an AR fixes the Art. 14(7) coordinator CSIRT at step 1 of the cascade instead of leaving it to an importer, a distributor, or the Member State with the most users. The trade-off is now presented as a decision for the reader's own counsel.
• "Required" corrected to "optional" in the cheat sheet, shortlist, glossary, README.md, SKILL.md (twice), auditor-packet/00-INDEX.md, the DoC template, and the technical-documentation outline.
• Appointment status removed. The status line, target dates, third-party vendor shortlist, and "Placeholder identity" block are gone, along with the 🟠 In progress — appointment underway row in wolfssl-inc-auditor-packet/00-INDEX.md. The packet no longer asserts that an appointment is underway, and does not assert the opposite either.

3. ROADMAP

Removes cra-kit/ROADMAP.md (44 lines) and all remaining links and text references to it. The deletion happens in this PR. Its practical content is not lost: CRA_LICENSE_OVERRIDE, SOURCE_DATE_EPOCH, pkg:github and make bomsh are all covered in README.md, the glossary, the cheat sheet, and SKILL.md.

Also: conformity-assessment-route.md drops internal-correspondence detail from a customer-facing template.

Test plan

• cra-kit/scripts/validate.sh passes (auditor packet validation OK)
• cbom-draft.cdx.json still parses as valid JSON
• No remaining ROADMAP references in cra-kit/
• No remaining claim that an AR is required, and no appointment status, dates, or vendor names
• 00-INDEX.md status matches vulnerability-handling-process.md

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #603

No scan targets match the changed files in this PR. Review skipped.

[MarkAtwood]

Superseded. I had pushed these fixes onto this branch, which was the wrong call: it took over Sameeh's PR and left him unable to approve his own work. The branch is reset to his commit and the same findings are now review suggestions he can apply directly. Original text below for the record.

---

Direction is right and I've landed it. The SRP/CSIRT correction is worth having
in before Art. 14 applies on 11 September, so rather than round-tripping I pushed
the fixes to your branch directly. Details so nothing is a surprise.

Citations corrected. These were the substantive ones:

• EUVD publication is Art. 17(5), not 16(2). 16(2) is CSIRT-to-CSIRT
  dissemination. 17(5) also has a qualifier worth keeping: ENISA adds the entry
  "in agreement with the manufacturer". Also noted the EUVD itself is
  established under NIS2 Art. 12(2), not by the CRA.
• Severe-incident deadlines are Art. 14(4)(a)-(c), not 14(3). 14(3) is the
  duty to notify; the one-month final report is 14(4)(c). Your 14(2)(a)-(c) cites
  on the 24h/72h/14-day rows were right, since that's the vulnerability track.
• Support period is Art. 13(8). 13(2) is the risk-assessment duty. That one
  was pre-existing in the glossary, not yours.

Two things that would have misled a reader.

Art. 14(7) isn't a single AR rule. With no EU main establishment it's an ordered
cascade: authorised representative, then importer, then distributor, then user
count. I've stated the cascade.

More important, ENISA's guidance says coordinator-CSIRT validation runs in
parallel with reporting and is "not a prerequisite for fulfilling the CRA
reporting obligation". As written it read as a gate on filing, which is the kind
of thing that costs someone the 24-hour clock. Also worth knowing: ENISA's "AR"
in the SRP docs is Assigned Representative, a platform seat, not the Art. 18
authorised representative. Easy trap, flagged inline now.

One place the correction overshot. Art. 14(1) requires notification
"simultaneously to the CSIRT designated as coordinator ... and to ENISA", and
14(7) has it "simultaneously accessible to ENISA". So ENISA is a co-addressee by
statute, not a CC, and "reports are not sent to ENISA directly" swings too
far the other way. Reframed as: one submission via the SRP satisfies both. The
old text was imprecise about the mechanism, not wrong about ENISA.

Nits: canonical SRP URL (yours 301-redirects), and the No ─▶ standard line
in the ASCII box was 19 columns against an 18-column border. It was 17 before, so
the edit flipped the error rather than fixing it. Realigned.

Added: Art. 69(3) and Art. 71(2) to the references. Worth having explicitly,
because 69(3) derogates from the usual grandfather rule and applies Art. 14 to
products placed on the market before 11 Dec 2027. That means from 11
September the 24-hour clock covers the existing installed base, not just new
releases.

---

What I pulled back out, and why.

The status flip to a committed Art. 13/14 statement, and the on-call rewrite, are
reverted. Not because they're wrong. Because they're public compliance
commitments rather than accuracy corrections, and they should carry their own
sign-off rather than ride in on a docs PR. Please do re-raise them separately.

One specific thing to fix before that lands: the PR asserted that the
acknowledgement and triage targets are "reflected in the public CVD policy at
/.well-known/vulnerability-disclosure-policy.txt". They aren't. The published
policy commits to acknowledging "without undue delay" and states no hour targets
at all; "triage" doesn't appear on the page. An auditor follows that link and the
packet takes the credibility hit. Either the numbers go on the published policy
first, or the claim comes out.

Related and worth a follow-up regardless: §4 of that same live policy still says
"We report actively exploited vulnerabilities to ENISA in accordance with Article
14" — exactly the phrasing this PR corrects in the kit. The kit and the page it
cites as a reference template now disagree, so the same fix wants to land on
wolfssl.com.

Separately, a decision that lands on your AR bullet: we're not appointing an
Art. 18 authorised representative. Art. 18(1) says a manufacturer may appoint
one, and there's no "shall appoint" anywhere in the CRA. I removed the bullet
tying the reporting end-point to an AR appointment; a follow-up PR restates
wolfSSL Inc.'s position and fixes the eleven places the kit told customers an AR
was required.

[MarkAtwood]

Mechanics corrections are right and verified against the OJ text. Fixes pushed to the branch; status change deferred to its own PR as noted above.

[MarkAtwood]

Sorry for the mess on your branch, that was my doing and you were right to call it. I have reset the branch back to your commit, so this is yours again and you can merge it once these are in.

The SRP/CSIRT direction is right and worth landing before Art. 14 applies on 11 September. Findings below are mostly one-click suggestions. The two that matter are the CVD policy claim and three article cites.

Numbers verified against the OJ text of Regulation (EU) 2024/2847 and the latest consolidated 2019/1020.

Downgrading to comments. None of these block the merge; the citation corrections and the CVD-policy wording will land in a follow-up PR so this can go out for the webinar. Suggestions remain inline for reference.

[MarkAtwood]

Approving to unblock the webinar. The SRP/CSIRT correction is the right direction and is a clear improvement on what is on master.

Inline suggestions above are not blockers and stay for reference. I will land them in a follow-up PR of my own rather than touching this branch: three article citations (EUVD is 17(5) not 16(2), severe-incident deadlines are 14(4)(c) not 14(3), support period is 13(8) not 13(2)), the Art. 14(7) four-step cascade, the SRP validation wording, and the ASCII box alignment.

One to carry into whatever PR re-raises the status change: the published CVD policy still commits only to acknowledging "as they come in", with no hour targets, so the sentence claiming the 24h/72h targets are reflected there needs the numbers published first or the claim dropped.

[MarkAtwood]

Merging with an admin override, and that is on me.

I pushed commits to this branch earlier, which I should not have done on someone else's PR, then pushed again to reset it back to @sameehj's commit. Branch protection requires the last push to be approved by someone other than the pusher, so my own approval does not count and this cannot merge normally. Sorry for the churn.

Rather than make Sameeh push again to work around my mistake, I am overriding. CI is green across all 200+ jobs and the commit is entirely his.

The citation corrections and the CVD-policy wording are deferred to a follow-up PR of mine. They are not blockers and this should not wait on them.

[sameehj]

Thanks Mark — all eight suggestions applied in 9a26efb, plus the scope change you asked for.

Applied as suggested

• Art. 14(1)/14(7): ENISA is a co-addressee, not a copy recipient. The "not sent to ENISA directly" framing is gone.
• Art. 14(7) four-step cascade instead of the single-AR rule.
• SRP validation runs in parallel and does not gate a filing; "Assigned Representative" is a platform role, not the Art. 18 AR.
• EUVD publication is Art. 17(5), in agreement with the manufacturer; EUVD established under NIS2 Art. 12(2).
• Severe-incident deadlines are Art. 14(4), one-month final report at 14(4)(c).
• Support period is Art. 13(8).
• Triage box content line was one column wider than its border. Confirmed: 50 vs 49. Fixed.

Scope, per your line-3 comment
The status flip and the on-call rewrite are out. vulnerability-handling-process.md is back to 🟡, on-call is back to 🟠, and 00-INDEX.md matches. Both will come back as their own PR with sign-off. Your blocker on the SLA clause resolves with that, since your suggested text is the original wording.

Four changes beyond your suggestions — please check these

1. References list still read "Art. 16: Single Reporting Platform; EUVD publication". Split into Art. 16 (SRP) and Art. 17(5) (EUVD). Same error you flagged, two sections down.
2. 00-INDEX.md timeline still read "24h ENISA early-warning". That is the wording this PR exists to remove, so I fixed it.
3. Glossary CSIRT row still tied the coordinator to the AR's Member State. Now uses the Art. 14(7) cascade, to match the process doc.
4. The on-call revert is not byte-identical to the original. The original said "the 24h ENISA clock"; it now says "the Art. 14 24-hour clock". Reverting that phrase verbatim would reintroduce the error.

Left alone, needs its own PR
Your note says we have decided not to appoint an Art. 18 authorised representative. eu-authorised-representative.md and its 00-INDEX.md row ("appointment underway") still assume we will. Out of scope here.

cra-kit/scripts/validate.sh passes. Over to you for the re-approval — the push was mine this time, so yours will count.

[MarkAtwood]

Approved.

Verified all four of your beyond-suggestion changes against the diff: the Art. 16 / Art. 17(5) references split, the 00-INDEX timeline wording, the glossary CSIRT row using the Art. 14(7) cascade, and the non-identical on-call revert. Agreed on the last one, a byte-identical revert would have reintroduced the '24h ENISA clock' wording this PR exists to remove. Good catch.

Scope revert is clean: vulnerability-handling-process.md stays 🟡, on-call stays 🟠, 00-INDEX matches. validate-auditor-packet and the rest of CI are green, 200/200.

Two notes, neither blocking:

1. This PR deletes cra-kit/ROADMAP.md (44 lines). The title reads as cleanup of references to an already-deleted file, but the deletion happens here. Flagging so it is on the record rather than a surprise later.

2. Agreed the Art. 18 AR item is out of scope for this PR. Worth prioritising the follow-up though: 00-INDEX.md still shows 'In progress, appointment underway' while we have decided not to appoint one, so the auditor packet currently states an appointment that is not happening. That should not sit in front of an auditor for long.

[sameehj]

Thanks Mark. Both notes taken, and the second one turned out to be bigger than either of us thought.

ROADMAP. You are right, the title read backwards. Retitled to cra-kit: correct Art. 14 reporting mechanics (SRP/CSIRT/EUVD) and remove ROADMAP.md so the deletion is stated, not implied. I also rewrote the description: it still carried the status-flip and on-call bullets from before the scope revert, so it advertised changes the diff no longer contains. The body now matches the diff, records the 44-line deletion explicitly, and notes that the practical content of the removed table (CRA_LICENSE_OVERRIDE, SOURCE_DATE_EPOCH, pkg:github, make bomsh) survives in README.md, the glossary, the cheat sheet, and SKILL.md.

Art. 18. Agreed it should not sit in front of an auditor, and while scoping the follow-up I found a straight legal error underneath the status contradiction.

Art. 18(1) reads: "A manufacturer may, by a written mandate, appoint an authorised representative." It is permissive. There is no obligation to appoint one, including for a manufacturer established outside the Union. I checked the usual escape hatch too: Art. 66 CRA only adds the CRA to Annex I of Regulation (EU) 2019/1020, which is the market-surveillance list. It does not bring the CRA under Art. 4 of that Regulation, so there is no back-door requirement for an EU-established economic operator either.

The kit currently states the opposite in two places:

• eu-authorised-representative.md — "CRA Art. 18 requires manufacturers established outside the EU to appoint … an Authorised Representative".
• Same file, "What this means for customers" — tells readers "you face the same Art. 18 obligation".

The second is worse, because it is customer-facing advice about a duty that does not exist.

So the follow-up will do three things rather than one:

1. Correct "requires" to "may" in both places, and drop the customer-facing obligation claim.
2. Remove the appointment status, the target dates, the vendor shortlist, and the "Placeholder identity" section, so the page stops asserting an appointment is underway without asserting the opposite either.
3. Update the 00-INDEX.md row to match.

Nothing else in the kit needs to move. The glossary CSIRT entry and the new vulnerability-handling-process.md bullet already give the full Art. 14(7) cascade — AR, then importer, then distributor, then the Member State with the most users — so they stay correct with no AR in place.

Merging this one now.

[sameehj]

@MarkAtwood heads-up: I pushed a4110d3 and it dismissed your approval. That was deliberate rather than accidental — the Art. 18 item you asked me to prioritise turned out to be a legal error, not just a stale status row, so folding it in here rather than deferring it seemed better than leaving a wrong statement in a merged kit. Sorry for the re-review.

What changed since you approved. One commit, 11 files. Nothing in the Art. 14 / SRP / EUVD work moved.

You flagged that 00-INDEX.md still said "In progress, appointment underway" while we have decided not to appoint one. Correct. But underneath that, the kit also said an AR was mandatory, in eight places. Art. 18(1) reads:

A manufacturer may, by a written mandate, appoint an authorised representative.

Permissive. No duty to appoint one, including from outside the Union. I checked the indirect route too, since that is where this normally bites: Art. 66 CRA adds the CRA only to Annex I of Regulation (EU) 2019/1020, the market-surveillance list. It does not bring products with digital elements under Art. 4 of that Regulation, so there is no back-door requirement for an EU-established economic operator.

Worth noting which way the error cut. CRA-Compliance-Shortlist.md, CRA-Cheat-Sheet.md, the glossary and README.md are customer-facing, and they were telling readers they had an obligation that does not exist.

The three things the commit does:

1. Corrects "required" to "optional" in the cheat sheet, shortlist, glossary, README.md, SKILL.md (twice), auditor-packet/00-INDEX.md, the DoC template, and the technical-documentation outline.
2. Rewrites eu-authorised-representative.md around the real mechanism — Art. 18(3) mandate scope, the Art. 18(2) exclusions, and the fact that an AR fixes the Art. 14(7) coordinator at step 1 of the cascade rather than leaving it to an importer, a distributor, or the Member State with the most users. The trade-off is framed as a decision for the reader's own counsel.
3. Removes the appointment status, target dates, vendor shortlist, and "Placeholder identity" block, and the 🟠 row in wolfssl-inc-auditor-packet/00-INDEX.md. The packet now asserts neither that an appointment is underway nor that one has been ruled out.

Two things to look at specifically:

• The rewrite drops the line the earlier commit added to eu-authorised-representative.md about the AR determining the reporting end-point. That claim was fine in isolation but presupposed an AR. The net diff against master no longer adds it, though 07efe62 adds it and a4110d3 removes it, so it is visible in the commit history.
• The glossary CSIRT row and the Art. 14(7) cascade in vulnerability-handling-process.md are untouched and stay correct with no AR in place. That is the reason nothing else had to move.

scripts/validate.sh passes. Since this is a legal-position change in customer-facing material rather than a wording fix, flag it if you want counsel to confirm the reading before merge.

[MarkAtwood]

Approved. Checked 18(1), 18(2), 18(3), Art. 66 and Annex V point 2 against the OJ
text, all correct. No counsel needed for the reading, the "may" is on the face of it.

Four for later, none blocking:

• Art. 14 isn't in the 18(2) list (that's 13(1) to (11), 13(12) first subpara, 13(14)).
  A mandate can cover the filing; only the duty can't move. Worth splitting that sentence.
• Shortlist line 98 still calls the EU AR appointment "in flight", now the last place
  in the kit saying we're appointing one. Same for "EU AR status" in Shortlist 95,
  README 18, SKILL 26 and 39.
• The page is generic now. It belongs in cra-kit/ next to the glossary rather than in
  the company packet.
• 00-INDEX: every row has a status glyph except this one.

Right call folding this in instead of deferring it.