Main site

Electronics AI agent · CRA reporting

CRA Vulnerability-Reporting AI Agent

Draft the Article 14 report from evidence already assembled — the exploitation proof, the models still in the field, the date a fix became available — and leave the trigger to a named person.

Typical delivery
4–6 weeks
Deployment
Your stack
Named reporter
Evidence first
After launch
Agent Care

What this agent does

Drafts the report, never the trigger

In

  1. 01

    A report of exploitation arrives, and the clock runs from awareness, not from the day the ticket was triaged.

  2. 02

    A finding meets Art. 3(42) only on reliable evidence of exploitation, never on a severity score.

Reason

  1. 03

    A legacy model stays in scope — Art. 69(3) reaches products placed on the market before 11 Dec 2027.

  2. 04

    An incident is read against the Art. 14(5) limbs, the capable-of limb included, by a named person.

  3. 05

    A fix becomes available, and that date, not the drafting date, starts the 14-day clock.

Decide

  1. 06

    A severe incident closes one month after the notification, so the two final clocks never run together.

  2. 07

    A channel is checked before it is needed — ENISA had published no platform URL and no API on 23 August 2026.

Out

  1. 08

    A record is kept whole — the evidence, the estate it reached, the drafts and the person who submitted.

  2. 09

    Execute write actions only inside the approval boundaries agreed during implementation.

Product statement

The agent drafts and keeps the record; a named person decides the trigger is met, signs the report and submits it, and the manufacturer answers for it.

Example workflow

One finding, evidence to submission

  1. 1Exploitation evidence receivedVulnerability tracker, researcher report, telemetry or a CSIRT contact
  2. 2Affected estate assembledSKUs, firmware ranges, legacy models still in the field and the component mapping behind each
  3. 3Report draftedEarly warning, notification and final report against the fields ENISA publishes
  4. 4Controls appliedClock checks, evidence-sufficiency checks, estate-coverage checks and completeness confidence

No human action required

Stages 1 to 4 run unaided, and nothing is reported at any of them — the agent is drafting, and the product security lane opens at the completeness gate.

5DecisionBranches at the completeness gate
Evidence sufficient

Goes to the product security lead to submit.

Anything thin

Adds a regulatory counsel read first.

Product security review

The draft is held with its clocks, its evidence and its gaps.

Submit the report · Append evidence · Send to counsel

Submitted — by a named person

  1. 6Tracker and case records updatedOnly where write access and disclosure policy allow it
  2. 7Outcome evaluatedClock margin, evidence completeness, counsel corrections and what a later review found

Corrections

Each counsel correction is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Deciding a vulnerability is actively exploited.
    • Submitting to a CSIRT, to ENISA or to any authority.
    • Signing or sending an early warning.
    • Deciding an incident is severe under Art. 14(5).

  • Automation boundary

    Agent acts unaided

    • ✓Assemble the exploitation evidence and name the source it came from.
    • ✓Run each reporting clock from the moment of awareness.
    • ✓Map a component finding to the SKUs your SBOM depth reaches.
    • ✓Draft the report against the fields ENISA publishes.

    Nothing reaches an authority except by a named person, inside the agreed boundaries.

    • Judging that a legacy model has left scope.
    • Telling a user their product is unaffected.
    • Setting a support period, or reading one into a DoC.
  • Changes to trigger rules, clocks or report templates.

Example output

One finding, annotated

No platform URL and no API were published on 23 August 2026, and the record is what a person submits from.

Report draft · single finding

Illustrative example
Finding
Gateway firmware, legacy range
Drafted as
Early warning, actively exploited, evidence attached
Clock
Hour 9 from awareness
Evidence of record
Researcher packet, 21 August 2026
Confidence
Held unsubmitted
Held for
The product security lead, in person

As received

Taken from the researcher packet and the build inventory — the mapping reaches as far as the SBOM does.

What the record holds

  • The exploitation proof
  • Affected-range mapping
  • Fix-availability date

Why no trigger call here

Reliable evidence is the Art. 3(42) test, and the July 2026 guidance is non-binding.

What the score decides

Below the configured threshold the draft picks up a counsel read before.

Action

Submit the reportAppend evidenceSend to counsel

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every finding

From the vulnerability tracker

03Evidence

One product, one regulation

R155 type approval belongs to our automotive agent and plant OT to our manufacturing one; this is a product in the field.

01Approved path

What the evidence showed

Art. 69(3) applies Article 14 to every in-scope product placed before 11 December 2027 — the date Art. 64 penalties start.

02Human review

Where the support period lives

In the notice our firmware agent echoes, not in the EU declaration of conformity — and Art. 13(8) sets a floor that expected use time can lower.

04

Build an evidence trail

The evidence, the product range it reached and the person who reported stay on the record.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Reporting channels

    • ENISA Single Reporting Platform
    • Coordinating CSIRT contacts

  • Vulnerability sources

    • CVE feeds
    • researcher reports
    • Telemetry
    • threat intelligence

  • Product and build records

    • PLM
    • build inventory
    • SBOM
    • component mapping

Agent

CRA vulnerability reporting

  • Reads the evidence
  • Drafts the report
  • Holds for the reporter

  • Case and ticket systems

    • Jira
    • ServiceNow
    • PSIRT case records

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six meshes between the model and the report

Six meshes, the coarsest first. Whatever falls through every one of them is set out in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modePull the agent back to evidence assembly only when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, trigger-rule and field changes; the Art. 14(10) act is not adopted.Track
L4TraceabilityRecord the evidence, the clocks, the estate mapped and each read of the draft.Record
L3Reporter releaseHold the draft for a named human; it governs submission, and not whether the trigger is met.Gate
L2Policy guardrailsTest the draft against the clocks, the Art. 14(5) limbs and your SBOM depth; no format is mandated.Restrict
L1Confidence thresholdsRoute a thin draft to a counsel read before the product security lead sees it.Require review
Model coreDraft assembled — the evidence, the clocks, the estate reached and completeness
L1 – L2
Test whether a draft may stand
L3
Puts the submission in a person's hands
L4 – L5
Keep the finding and the evidence behind it
L6
Holds the finding unreported when signals degrade

How Nestack evaluates it

Evaluate the whole assembly — not only the draft that comes out.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the report an authority reads

  1. E1Final-output evaluationDid the draft record the evidence that started the clock?
  2. E2Step-level evaluationDid the agent use the right clock, the right estate and the current fix date?
  3. E3Tool evaluationDid it read and write the correct finding and the correct product record?
  4. E4Confidence calibrationDo low-confidence drafts actually attract more counsel corrections?
  5. E5Slice evaluationHow does performance change across specific product families?
  6. E6Business outcomeHow many drafts needed a correction before the lead submitted them?

Floor — the outcome the manufacturer answers for

Failure modes

Where each failure originates in the agent

Seven failure modes, placed at the stage where each one actually starts.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • IC-03

      Superseded advisory

      The evidence read comes from a withdrawn advisory.

    Stage gathers

    The evidence, the estate, the clocks and the fields

  2. 02 · Reasoning

    2 modes

    • IC-04

      Trigger read from a score

      Severity stands in for evidence of exploitation.

    • IC-06

      Legacy estate dropped

      Products placed before 2027 fall out of the draft.

    Stage proposes

    The evidence, the clocks applied and completeness

  3. 03 · Tool / write

    2 modes

    • IC-02

      Clock started from triage

      The clock runs from the ticket, not from awareness.

    • IC-05

      Wrong final clock run

      The one-month clock is run from the fix date.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • IC-01

      Reported, evidence unrecorded

      The record shows a submission but not what produced it.

    Stage returns

    The report a person signs and the authority reads

  5. 05 · Change / Version

    1 mode

    • IC-07

      Silent trigger regression

      A rule change moves the trigger without moving the record.

    Stage tracks

    Model, prompt, trigger rules and report fields

  • Sev-1 · a report leaves without a person
  • Sev-2 · a wrong trigger reaches the record
  • Sev-3 · source degrades, draft holds unsent
See the complete Electronics failure-mode catalogue

Affected slices

One product family absorbs the corrections

A portfolio-level trigger-evidence figure can read clean while one product family absorbs most of the corrections. Nestack reports the counsel-correction rate by product family, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Legacy models still in the field10.4%3.6×Review
Products on third-party stacks7.9%2.8×Review
Connected consumer devices4.8%1.7×Watch
Current-generation industrial units1.9%0.7×Normal

Bar: counsel-correction-rate lift vs. current-generation industrial baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

What an unreconstructable record costs

A cycle closes when the missed legacy model is a regression case. That suite is what the next report drafted is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Counsel-correction rate rises in one product family.

  2. 02

    Diagnose

    The exploit report that named a model line nobody still shipped is read back until one cause remains.

  3. 03

    Improve

    The change ships numbered, and the findings that forced it ride with it.

  4. 04

    Verify

    Nothing releases while one touched product case is still red.

  5. 05

    Learn

    It is kept permanently, and the trigger rules are amended in the very same commit.

  6. Learn → Detect

    The return edge. The next report is measured against a suite one case longer.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, report assembly, evaluation, integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Reporting-workflow discovery and boundary definition.Week 1
  2. 02Tracker, PLM and telemetry sources.Week 1, Week 2
  3. 03Trigger-rule, clock and affected-estate mapping.Week 1, Week 2
  4. 04Evidence ingestion and normalisation.Week 2
  5. 05Estate, component and SBOM-depth binding.Week 2, Week 3
  6. 06Completeness scoring and counsel routing.Week 3
  7. 07Reporter submission workflow.Week 3, Week 4
  8. 08Tracker and case-system integration.Week 5
  9. 09Trigger and evidence cases.Week 4, Week 5
  10. 10Guardrails and reporting controls.Week 4
  11. 11Finding-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne product family, one channelProductionProduction reporting workflowAdvancedMultiple families / regions
Introduced at Pilot
Report drafting to your rules✓✓✓
Named-reporter submission✓✓✓
Product-estate baseline✓✓✓
Introduced at Production
Reporting by product family—✓✓
Submission workflow in your systems—✓✓
Approved write-back—✓✓
Vulnerability-tracker integration—✓✓
Introduced at Advanced
Multi-authority reporting duties——✓
Cross-family evidence packs——✓
High finding volume——✓
Multi-authority notification controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01Your product estate and build records

    Estate ingestion and component mapping

    Week 1

  2. 02Representative findings and advisories

    Draft baseline, clock binding and evidence capture

    Week 2

  3. 03Your trigger rules and reporting channels

    Trigger-rule, clock and channel mapping and the automation boundary

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Tracker, PLM and telemetry assessment, then integration setup

    Week 2

  5. 05Findings you would not want reconstructed

    Trigger cases and failure-mode testing

    Week 4

  6. 06What no draft report may assert

    Completeness scoring, counsel routing, guardrails and submission controls

    Week 3

  7. 07A named product security lead to submit

    Reporter submission workflow, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

These bands are the weeks each phase honestly costs, and that is why the fifth of them carries two.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Reporting workflow discovery, trigger mapping and the automation boundary

W2Source integration and the estate baseline

W3Draft assembly, clock logic and submission controls

W4Evaluation suite, trigger cases and failure-mode testing

W5Tracker integration, pilot findings and targeted corrections

W6One reporting quarter run under the product security lead, then Agent Care handover

Reading the band
A bar covers only the weeks its own work is named in. The doubled fifth week is real work, not padding.
At the end of W6
Validation closes on live findings, and Agent Care picks up the watch.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Electronics AI agent

Build a CRA reporting agent around a clock that starts without warning.

Show us how a finding reaches you today and who submits on 11 September. If anything you placed on the market before December 2027 is still in the field, then Art. 69(3) already puts it inside Article 14, and the record is read back long after.

Typical delivery
4–6 weeks
Deployment
Your vulnerability tracker
Named reporter
Evidence first
After launch
Agent Care available

Nestack Agents · CRA vulnerability reporting

AGT-EL-12 · Agent Care available after launch

Build a CRA reporting agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your products

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.