# The Assigned Representative on the SRP: who it is, and how to choose it by company size

> The 24 hours for the early warning run on a Saturday too, and a specific person makes them run. Who the Assigned Representative on the ENISA platform is, why it is not the CRA authorised representative, and how to choose it from the micro-firm to the multinational.

- URL: https://albertoscarpa.com/blog/en/choosing-the-assigned-representative/
- Lingua / Language: English
- Published: 2026-08-12
- Tags: CRA

---

The 24 hours for the early warning run on a Saturday too, and a specific person makes them run: whoever holds the account on the platform and the authority to notify. On this choice a company stakes the difference between an orderly obligation and a deadline missed because the only person who knew how to do it was on holiday. That role is the Assigned Representative (AR). Choosing it is a process decision, to be taken before the platform launches.

For the full picture of the platform and the deadlines, the starting point is the guide [The CRA Single Reporting Platform](/guide/en/single-reporting-platform-guide/).

## Two representatives not to be confused

The name is misleading. The Assigned Representative on the Single Reporting Platform (SRP) is not the "authorised representative" of the Cyber Resilience Act (Art. 3(15) and Art. 18: a person established in the Union with a written mandate from the manufacturer). The AR on the platform is whoever operates the SRP and submits the notifications on behalf of the manufacturer.

For a manufacturer established in the EU the AR is an authorised internal person, and the distinction stays clear. For a non-EU manufacturer the two roles tend to coincide, and the overlap has a practical consequence: the establishment of the authorised representative determines the competent coordinating CSIRT (Art. 14(7), third subparagraph, point a). Whoever sells into Europe from outside chooses, along with the representative, also the national authority it will answer to.

## One role, three functions

The AR gathers into a single role three functions that in large companies sit on different people:

- Assess: is the report an active exploitation? is it a severe incident? It is a technical judgement.
- Decide: authorise disclosure, mark the sensitivity level or the exceptional circumstances, commit the company. It is a judgement of responsibility.
- Operate: fill in and submit on the platform within the deadlines. It is execution.

Choosing the AR means deciding how to distribute these three functions. In a small structure they sit on the same person; as the company grows they separate, and the choice becomes a matter of governance, not the appointment of a single individual.

## The four criteria, valid at every size

Authority: the AR must be able to decide under deadline, not just execute. A notification involves disclosure choices that must be made within hours.

Technical knowledge of the product: the fields of the 72 hours and the final report ask for the nature of the vulnerability, of the exploit, of the corrective measures. Whoever operates must understand what they are writing.

Reachability within 24 hours, weekends included: hence the backup is mandatory, not optional. A single AR is a single point of failure with a legal deadline attached.

Continuity: the AR should be defined as a role with a named deputy, so that it does not vanish when a person changes job.

## How it changes with company size

### Micro-firm (under 10-15 people)

The three functions collapse onto one or two people. The primary AR is the CTO or the technical owner, the one who knows the firmware and can tell whether an exploit is real; the backup is the owner or a second engineer. The dominant risk is the single point of failure: if the only person who can notify is on holiday, the 24 hours run anyway. An external consultant can support the assessment, while the account stays with the manufacturer. Here the choice is not "who", it is ensuring that at least two people can act.

### Small (15-50 people)

This is the first level where it pays to separate the assessing from the operating. The primary AR sits with the product or quality lead, the backup with an R&D lead. A short written escalation is needed: who estimates the technical severity, who authorises submission, in what order they are called. One page, not a manual.

### Medium (50-500 people)

The AR should be made a formal role, such as a Product Security Officer or the head of even a light PSIRT, with a named deputy and tied to the existing incident response process. Governance becomes a matrix: R&D assesses, management or legal authorises disclosure and the marking of exceptional circumstances, the AR operates the platform. Whoever already has a certified quality system or an IEC 62443 path has the vulnerability handling process (Art. 13; Annex I, Part II, point 5) on which to rest all of this.

### Large and multinational

The problem becomes the mapping of legal entities. The SRP associates the AR with a manufacturer, and the main establishment determines the CSIRT (Art. 14(7)): a group with several manufacturing entities across several Member States may end up with different coordinating CSIRTs for different entities. Several manufacturer registrations are needed, each with a primary AR and a backup, plus a central PSIRT that coordinates to avoid duplicate or inconsistent notifications on the same product. For a non-EU headquarters, the authorised representative under Art. 18 established in the Union is required, and its establishment fixes the competent CSIRT.

## Reachability: the coverage must be double

The three functions all need coverage inside the 24-hour window: the intake that raises the alert, the technical assessment, the authority to open. If the technical person is reachable but cannot authorise, or the decision-maker is reachable but cannot assess, the process blocks anyway. Covering only the technical side leaves uncovered the point where the notification actually opens.

The mechanism that makes coverage of the authority sustainable is pre-delegation. The owner does not need to be reachable every weekend: what is needed is a written pre-authorisation for the on-call AR to submit an early warning, on credible suspicion, without waiting for a signature. The early warning is minimal, preliminary and correctable (Art. 14(2)(a)), so its submission is a low-risk decision and delegable. The heavy decisions stay at the top, the marking of exceptional circumstances and public disclosure, which live in the window of the 72 hours and the final report, where there is time to escalate. Reachability of the authority is obtained by pre-delegating the one decision with a 24-hour deadline, not by putting the owner on guard duty.

How you reach the decision to open, with a silent reporter or a non-technical AR, is in [From report to notification](/blog/en/from-report-to-notification/).

## What to do now

> Operational note (my indication, not legal text). The appointment of the AR is closed before the platform launches, in three moves. Define the role, not the person: primary AR and backup as functions, with interchangeable names. Create the two EU Login accounts right away, the one step that does not depend on the SRP going live. Write one page of escalation that states who assesses, who authorises, who operates, with which contacts reachable during closure periods, and the written pre-delegation of the early warning to the on-call AR.

The choice of the AR does not measure the maturity of your products, it measures the readiness of your process. A company with still-immature products but with AR, backup and escalation defined arrives ready for the September 2026 deadline; one with mature products but nobody who can notify on a Saturday does not.

---

*References: Regulation (EU) 2024/2847 (CRA), Art. 3 (points 15 and 42), Art. 13, Art. 14 (in particular par. 7), Art. 18 and Annex I, Part II, point 5. Non-binding guidance: ENISA pages on the SRP and related FAQ (updated 3 August 2026). The notes flagged as operational are my interpretations, not regulatory text. Article numbers verified against the official text of the CRA.*
