CRA Vulnerability Reporting: A 24-Hour Model for Thai Manufacturers

The EU Cyber Resilience Act (CRA) reporting obligations began to apply on 11 September 2026. Thai manufacturers that develop industrial machinery, IoT devices or embedded software for the EU market now need an operating model that moves CRA vulnerability reporting from the 24-hour early warning to the 72-hour notification and the final report. This guide connects scope triage, PSIRT, product SBOMs, the ENISA Single Reporting Platform (SRP), RFP requirements, a 90-day implementation plan and acceptance testing.

Important: This article is an operational guide based on official information available on 20 September 2026. It is not legal advice. Applicability, the economic operator role, the need to report and the correct reporting route depend on the product, contract and EU distribution model. Confirm each case with qualified legal, conformity-assessment and cybersecurity professionals.

Why CRA vulnerability reporting is not just a documentation exercise

CRA preparation is often associated with secure development, technical documentation, CE marking and conformity assessment. Reporting is different: it is a live process whose clock starts with an event. Once a manufacturer becomes aware of reliable evidence of active exploitation, or of a severe incident affecting the security of a product, an early warning is due without undue delay and in any event within 24 hours.

That focus differs from our ETSI EN 303 645 guide, which addresses general product-security evidence. It also differs from our OT cyber incident-response drill guide, which focuses on plant operations and recovery. This article addresses the manufacturer’s statutory reporting operation for products made available on the EU market.

A factory SOC may know how to contain malware in a production site and still be unable to answer the product questions that CRA reporting requires:

• Is the affected item an asset operated by the manufacturer, or a product supplied to customers?
• Which model, firmware, software component, customer population and Member States are affected?
• Is this an ordinary vulnerability, or is there reliable evidence of an actively exploited vulnerability?
• Could the event qualify as a severe incident affecting product security under Article 14?
• Which legal entity is the manufacturer, who makes the internal decision, and who submits through the SRP?
• Which CSIRT designated as coordinator (CDaC) is the correct destination?
• What can be stated as confirmed, and what remains unknown during the first 24 hours?

The 24-hour requirement is therefore not a form-filling task. It is a coordinated operation across the product register, product SBOM, vulnerability intelligence, EU distribution data, PSIRT decision-making, legal review, management escalation and SRP submission.

The statutory timeline after 11 September 2026

Article 14 of Regulation (EU) 2024/2847 and ENISA’s SRP FAQ define the following deadlines. Each is an outer limit; the underlying requirement is to report without undue delay.

The statutory trigger is not the date on which a CVE is published or a patch is finished. It is when the manufacturer becomes aware of the AEV or SI. Operationally, the organisation should start an internal clock when the first signal or candidate arrives so that investigation and escalation begin early; that internal clock does not replace the statutory awareness point. A case record should preserve distinct timestamps for intake, confirmation of reliable exploitation evidence, the determination of AEV or SI awareness, management and legal escalation, and submission. Collapsing them later into one time makes the decision trail difficult to explain.

Do not wait for a complete investigation before the 24-hour early warning

The early warning is not expected to contain a finished root-cause analysis or a complete population count. ENISA explains that some fields may not be required at the early-warning stage but become required in the 72-hour notification or final report. An effective draft separates confirmed facts, a reasoned initial assessment, unresolved questions and the next planned update.

This is not an excuse to leave basic data unknown. Product identifiers, Member States where the product has been made available, contact ownership and the awareness timestamp should be retrievable in normal operations. If a team spends the first 18 hours locating spreadsheets, too little time remains for decision-making, review and submission.

Keep AEV and SI classification distinct

Under the CRA, an AEV is a vulnerability for which reliable evidence shows that a malicious actor exploited it in a system without the system owner’s permission. “Potentially exploitable,” a published proof of concept, or a scanner finding does not automatically mean the same thing. A severe incident, by contrast, concerns an event that seriously affects—or is capable of seriously affecting—the product’s ability to protect the availability, authenticity, integrity or confidentiality of important data or functions, or that has led or could lead to malicious code being introduced or executed.

Classification may require legal interpretation, but engineering teams can prepare the evidence. Preserve relevant logs, the exploitation path, observed attacker behaviour, affected products and versions, reproducibility in customer environments, impact on data or functions, indicators of compromise and verified interim mitigations. Mark each item as fact, assessment or assumption.

Make the product and role decision in the first 30 minutes

A Thai-built machine may contain a PLC, industrial PC, HMI, remote-service gateway, cloud dashboard, mobile app and open-source libraries. The OEM, ODM, brand owner, EU importer and distributor may all be different entities. It is unsafe for the IT department to select the reporting entity while product boundaries and economic operator roles remain unclear.

Use an initial triage sheet in this order:

1. Could the item be a product with digital elements within CRA scope?
2. Has the product been made available on the EU market, and under which model, brand, contract and route to market?
3. Is the organisation acting as manufacturer, authorised representative, importer or distributor for that product?
4. Is the event limited to corporate IT, or can it affect the security of the product?
5. What evidence indicates a possible AEV or SI?
6. Which product versions, components, Member States and users can currently be identified?
7. Who recorded the awareness timestamp, and on what evidence?

This sheet does not automate the legal conclusion. Its purpose is to give PSIRT, legal and conformity-assessment owners enough facts to decide quickly. Borderline products should have a defined escalation path to qualified specialists.

ENISA Single Reporting Platform and CSIRT routing

The SRP is the single CRA reporting platform developed, operated and maintained by ENISA. It became operational on 11 September 2026. Manufacturers submit mandatory AEV and SI notifications electronically, select the relevant CDaC, and report once rather than notifying multiple national authorities separately. The submission is generally made available simultaneously to ENISA, while the receiving CDaC disseminates relevant information to other CSIRTs and authorities as appropriate.

How a Thai-headquartered manufacturer selects a CDaC

ENISA’s FAQ, updated on 17 September 2026, states that only one notification is required for a given AEV or SI even when the manufacturer has multiple EU branches or a parent company outside the EU. The manufacturer must coordinate internally.

The EU main establishment is the Member State where decisions related to product cybersecurity are predominantly taken. If that cannot be determined, it is the Member State containing the EU establishment with the highest number of employees. Where the manufacturer has no EU main establishment, Article 14(7) applies the following order, based on information available to the manufacturer:

1. the Member State where the authorised representative acting for the highest number of the manufacturer’s products with digital elements is established;
2. if that does not apply, the Member State where the importer placing the highest number of those products on the market is established;
3. if that does not apply, the Member State where the distributor making the highest number of those products available is established;
4. if none applies, the Member State with the highest number of users of those products.

Terminology matters. ENISA calls SRP users Assigned Representatives (ARs). That operational SRP role is distinct from an authorised representative as an economic operator under the CRA. Internal procedures should not translate or abbreviate them into one ambiguous role.

ENISA maintains a list of CDaCs, updated on 10 September 2026. Do not guess the route from a sales-country list alone. Preserve the facts, the routing rationale and the reviewer. ENISA warns that selecting the wrong CDaC can result in a notification being invalidated and needing resubmission.

Build SRP access into the operating model

At launch, the SRP is available in English only. Assigned Representatives need personal EU Login accounts with MFA. A Primary AR creates the initial manufacturer association and may invite Secondary ARs. ENISA’s FAQ states that a manufacturer may have one Primary AR and up to 20 Secondary ARs. Both can submit and update notifications within their permissions, and ARs associated with the same manufacturer can continue a notification, except for drafts stored locally in the individual account.

ENISA says association verification takes place in parallel and does not prevent submission; with an active EU Login account, registration takes only a few minutes. Its guidance also advises registering when a notification is needed rather than creating unnecessary associations in advance. Operational readiness should therefore focus on approved people, MFA availability, English terminology, absence and leaver cover, peer review and evidence retention. For exercises, use current guidance and a controlled tabletop walkthrough rather than creating fictitious live notifications.

Turn the product SBOM from a file into a 24-hour query

The CRA defines an SBOM as a formal record containing component details and supply-chain relationships in the software elements of a product with digital elements. Merely storing an SBOM file is not operational readiness. The reporting process must be able to move from a vulnerable component to affected products, versions, builds, customers, Member States, support status and correction owner.

Data that must be connected

The factory asset inventory described in our OT asset management guide is not the same as a register of products supplied to customers. The former protects and maintains assets at the manufacturer’s own sites. The latter supports impact analysis and reporting for delivered products. They can share identifiers, but ownership, update rights and retention rules should remain explicit.

Vulnerabilities in third-party components

If an AEV appears in an open-source library or purchased module, do not conclude that it is irrelevant because the manufacturer did not write the code. Conversely, do not assume that every manufacturer using the component reaches the same reporting conclusion. Examine how the component is integrated, whether the vulnerable function is reachable, configuration and build options, affected product versions, reliable exploitation evidence and what the manufacturer actually became aware of. Compare those facts with the Commission guidance on third-party components and obtain professional confirmation.

The PSIRT record should contain the mapping to the manufacturer’s product, not just a copy of the upstream advisory. Record the exact component version, used functions, call path, external exposure, compile settings, compensating controls, affected releases, correction plan, supplier inquiry and verified customer mitigation.

Run 24-hour, 72-hour and final reporting through PSIRT

The first 24 hours: make the early warning achievable

These intervals are example internal targets, not statutory allocations. They create room for waiting and rework; they are never a reason to hold a report until hour 24.

The 72-hour notification: update the initial assessment

By the 72-hour stage, update the product and version, the general nature of the exploit or incident, the initial impact assessment, corrective or mitigating action already taken or planned, action available to users and the sensitivity of the information. If a patch is not ready, describe verified interim measures such as isolation, configuration change, feature disablement, increased monitoring or access restriction.

Manage changes explicitly. If an early hypothesis is disproved, do not simply overwrite it. Record what new evidence changed the assessment. ENISA notes that platform counters and reminders do not replace the manufacturer’s responsibility to calculate deadlines from awareness and report without undue delay. Maintain the authoritative clock in the internal case.

The final report: close correction and cause

For an AEV, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. It includes the vulnerability’s severity and impact, information on the malicious actor where available, and details of the security update or other correction. For an SI, the final report is due within one month after the 72-hour notification and includes a detailed incident description, severity and impact, likely threat or root cause, and applied and ongoing mitigations.

Do not close the internal case merely because a patch was published. Completion criteria should include population and distribution, signing, rollback, customer communication, deployment confirmation where feasible, residual risk, SBOM and technical-documentation updates, and prevention actions. The workflow also needs an owner for any intermediate report requested by the CDaC.

Divide responsibility between Thailand headquarters and EU operations

For a non-EU manufacturer, information is often split among Thailand headquarters, an EU sales entity, importers, distributors and service partners. A useful responsibility model separates decision, submission, technical correction and customer communication.

This RACI is only a starting point. Adapt it to the legal structure. The essential control is that leave, time zones or one unavailable approver cannot stop the process. Define the Thailand–Europe overlap window, and use an on-call role to open the case and prepare evidence before the next European workday begins.

CRA reporting requirements to put in an RFP

When procuring a PSIRT platform, SBOM system, vulnerability-intelligence service, case-management tool or external support, compare demonstrable outcomes rather than feature names.

Data and traceability requirements

• Reverse query from component to product, version, build, customer population and EU Member State.
• Acceptance of formats such as SPDX or CycloneDX, with checks for missing fields, duplicates and inconsistent versions.
• Ability to link CVEs, supplier advisories and exploitation evidence to a case.
• Version control for the early warning, 72-hour notification, final report and user communication under one case.
• Auditable timestamps for facts, assumptions, decisions, approvals and changes.
• Retention, access control and export aligned to product life and support periods.

Workflow and continuity requirements

• Distinct triage paths for AEV candidates, SI candidates and ordinary vulnerabilities.
• SLA calculations and stage-specific alerts based on the recorded awareness time.
• Roles for Thailand and EU teams, delegated approval, duty cover and escalation.
• English drafting and two-person review for the English-only SRP.
• Handover that does not depend on one Assigned Representative’s local draft.
• Evidence handling for SRP downtime, any necessary CDaC contact and submission after service restoration.
• Separation between internal automation and human SRP entry, because ENISA states that an API is not available in the initial release.

Security and evidence requirements

• Least privilege and MFA for vulnerability details, customer data and unpublished patches.
• Audit logs for exports, attachments, approvals and pre/post-submission changes.
• Masking so that production data is not copied into a test environment.
• Backup, restoration, hosting region, subcontractor and incident-notification terms.
• Readable export of cases, SBOMs and evidence at contract termination.

Do not ask a supplier simply to claim “CRA compliant.” Provide a scenario, input data, expected result and evidence. Legal decisions remain with accountable people; the system supports facts, timing and traceability.

A 90-day implementation roadmap

Days 1–30: define the scope and the clock

The first month should define when the reporting clock starts and who owns it, rather than waiting for a perfect platform.

• Build a scope register covering EU products, models, legal entities, brands and routes to market.
• Map manufacturer and other economic-operator roles; flag boundary products for professional review.
• Name the PSIRT lead, duty role, legal and conformity owners, EU owner and candidate SRP ARs.
• Establish intake channels for AEV/SI candidates and one awareness-time rule.
• Gather the facts needed for CDaC selection and schedule expert review.
• Draft early-warning, 72-hour and final-report templates with substitute approvers.
• Measure how long it takes to trace one representative product from SBOM to customer population.

Deliverables include the scope register, role matrix, triage sheet, deadline calculator, contact tree and notification templates. A decision that a product is out of scope should also retain rationale and approval.

Days 31–60: connect data and procedure

Connect product SBOM, build provenance, sales and installation, and support data through stable identifiers. Do not wait for every product to be perfect. Prioritise by EU exposure, connectivity, threat exposure and remaining support period.

• Define an SBOM quality gate for versions, dependencies and artefact linkage.
• Test the query from vulnerability information to affected products.
• Assign owners for importer, distributor, Member State and customer-contact data.
• Configure handover from the 24-hour stage to 72-hour and final reporting.
• Create an English glossary and review rules.
• Add a step to check the latest SRP guidance, CDaC list and Commission guidance.
• Establish supplier notification SLAs and a third-party component inquiry form.

Days 61–90: exercise the process and retain acceptance evidence

Use representative hypothetical scenarios rather than reading the procedure in a meeting. Clearly label the scenario as an assumption and do not use real customer or vulnerability data.

For example, assume that the PSIRT in Thailand becomes aware at 14:00 ICT of reliable exploitation evidence affecting a third-party library in an industrial gateway supplied to the EU. The 24-hour outer limit is 14:00 ICT the next day, and the 72-hour outer limit is 14:00 ICT three days later. This is a mechanically consistent training calculation, not a legal conclusion for a real event.

Time case creation, SBOM search, affected-version extraction, Member State extraction, AEV-candidate assessment, management escalation, English early-warning drafting, peer review, simulated evidence retention and 72-hour handover. Score elapsed time, missing data, rework, approval waits and successful delegation—not merely “pass” or “fail.”

Acceptance tests: verify reporting capability, not a software demo

Add internal target times, not just “within 24 hours.” Examples might be case creation within 30 minutes, impact extraction for a representative product within two hours, and a first early-warning draft within 12 hours. These are company-defined operating targets, not statutory numbers.

Common failures and practical corrections

Failure 1: Corporate SOC and product incidents remain in one undifferentiated queue

Corporate compromise and product impact can overlap, but their registers and external responsibilities differ. Define conditions that branch a common intake into a product-security case with a distinct ID.

Failure 2: The team waits for a CVE before starting the clock

CRA definitions do not make CVE assignment the only trigger. Record reliable exploitation evidence and awareness; track CVE and EUVD identifiers as supporting references.

Failure 3: The SBOM is a delivery file and the sales register stays isolated in ERP

Reporting needs a searchable relationship, not the existence of two files. Define keys and owners that connect component, artefact, product version, serial/customer population and Member State.

Failure 4: Everything is delegated to the EU sales office

The EU team may lead submission and authority interaction, but technical evidence, the SBOM and the correction plan often reside in Thailand. Use one case owner and a time-zone handover that produces one coordinated notification.

Failure 5: A complete root-cause analysis is demanded within 24 hours

The early warning is the first stage of an update process. State uncertainty, then update at 72 hours and in the final report. At the same time, do not leave normally available product, distribution and contact data unresolved.

CRA 24-hour reporting FAQ

Must every vulnerability be reported within 24 hours under the CRA?

Article 14 mandatory reporting concerns AEVs and severe incidents affecting product security. Do not automatically report every unexploited finding through the same external path. Assess the definition, evidence and product impact. ENISA says voluntary reporting will be added in a future SRP phase. Obtain professional advice for an individual case.

When does the CRA 24-hour clock start?

It starts when the manufacturer becomes aware of the AEV or SI. Depending on the facts, that may not be identical to intake, CVE publication or management approval. Preserve separate timestamps and the rationale for the awareness point.

Can a Thai company email ENISA directly instead of using the SRP?

Mandatory notifications are submitted through the SRP using the appropriate CDaC endpoint. If the SRP is temporarily unavailable, ENISA says the manufacturer should submit when it is restored. If immediate communication is considered necessary, the CDaC may be contacted directly, but the SRP submission is still required after restoration.

Is an SRP Assigned Representative the same as an EU authorised representative?

No. Assigned Representative is the ENISA platform role for Primary and Secondary AR users. Authorised representative is a CRA economic-operator concept. Keep them separate in role descriptions and translations.

Who reports an AEV in a third-party component?

The conclusion can depend on integration, impact, evidence and economic-operator role. Map the upstream information to the manufacturer’s actual product and compare the facts with Commission guidance. Do not assume either that the upstream party’s report removes the manufacturer’s responsibility or that every integrator has an identical obligation.

Is a product SBOM enough to complete CRA reporting readiness?

No. The SBOM must connect to product versions, builds, Member States, customer populations, corrections and notification cases. Deadline management, approval, SRP entry, user communication and final reporting are separate capabilities.

Can CRA implementation be completed in 90 days?

Not necessarily for every product and legal question. This 90-day plan establishes a minimum viable reporting capability for priority products and reaches an exercised, evidenced workflow. Remaining products, data-quality work and contract changes continue on a risk basis.

Conclusion: operate PSIRT, SBOM and EU distribution data on one clock

CRA vulnerability reporting is not won by fast form entry alone. A manufacturer must establish product and role scope, preserve the awareness time, trace product impact through the SBOM, route an early warning through the SRP to the correct CDaC, and carry evidence into the 72-hour notification and final report. For Thai manufacturers, the workflow must also connect Thailand engineering with EU accountability, Assigned Representatives, legal and conformity review, and user communication.

TOMAS TECH helps manufacturers in Thailand structure product registers and SBOM links, PSIRT workflows, RFP requirements, 90-day implementation plans and acceptance tests. We do not replace legal advice; we help create the technical and operational evidence that a qualified adviser needs. You can contact us while the programme is still at the planning stage.

References

1. European Commission, Cyber Resilience Act reporting obligations
2. ENISA, CRA Single Reporting Platform: Frequently Asked Questions
3. ENISA, Single Reporting Platform
4. European Commission, Cyber Resilience Act – Implementation
5. European Commission, Cyber Resilience Act summary
6. EUR-Lex, Regulation (EU) 2024/2847
7. ENISA, List of CSIRTs Designated as Coordinators
8. ENISA, CRA SRP Guidance – AR User Registration