Notificação de incidentes e vulnerabilidades ao abrigo do CRA

01O que deve ser notificado

O artigo 14.º do Cyber Resilience Act cria dois deveres de notificação para os fabricantes de produtos com elementos digitais. São mais restritos do que parecem à primeira vista: os erros de rotina e as correções comuns não estão abrangidos. Art. 14

• Vulnerabilidades ativamente exploradas; uma vulnerabilidade do seu produto relativamente à qual existem provas fiáveis de que um agente malicioso a explorou num sistema sem autorização do proprietário. Uma vulnerabilidade que descubra e corrija antes de ser explorada é tratada através do seu processo normal de processo de gestão de vulnerabilidades, e não através deste canal de notificação.
• Incidentes graves; um incidente que afeta negativamente, ou é suscetível de afetar negativamente, a capacidade do produto para proteger a disponibilidade, a autenticidade, a integridade ou a confidencialidade dos dados ou das funções. Os critérios de gravidade constam do artigo 14(5).

Os deveres não se limitam aos fabricantes comerciais. Responsáveis por software de código aberto têm obrigações de notificação próprias na medida em que estejam envolvidos com produtos com elementos digitais. Art. 24(3)

02Os três prazos

Cada notificação desenvolve-se em três fases, contadas a partir do momento em que tomar conhecimento da vulnerabilidade explorada ou do incidente grave. Os prazos são apertados e é por isso que a preparação conta. Art. 14(2)–(4)

• No prazo de 24hAviso prévio. Uma primeira notificação de que ocorreu uma vulnerabilidade ativamente explorada ou um incidente grave, incluindo, no caso dos incidentes, se há suspeita de que tenha sido causado por atos ilícitos ou maliciosos.
• No prazo de 72hNotificação de vulnerabilidade / incidente. Um relato mais completo: a natureza geral da vulnerabilidade e da exploração, uma avaliação inicial e as medidas corretivas ou de atenuação adotadas, bem como as que os utilizadores podem tomar.
• Relatório finalRelatório final. No caso de uma vulnerabilidade, o mais tardar 14 dias após a disponibilização de uma medida corretiva ou de atenuação. No caso de um incidente grave, no prazo de um mês a contar da notificação de 72 horas. Indica a descrição completa, a gravidade, o impacto e a correção aplicada.

Repare na assimetria da última linha: no caso das vulnerabilidades, o prazo é desencadeado pela existência de uma correção; no dos incidentes, pela notificação anterior. São mecanismos distintos e vale a pena inscrevê-los separadamente no seu manual de procedimentos.

03Quando começa

As obrigações de notificação são a primeira parte importante do CRA a entrar em vigor. Embora a maioria das disposições se aplique a partir de 11 de dezembro de 2027, o artigo 14.º aplica-se a partir de 11 de setembro de 2026; 21 meses após a entrada em vigor do Regulamento. A ENISA abriu a plataforma de notificação única nessa mesma data. Art. 71

04A quem notifica

As notificações são enviadas para ENISA e ao CSIRT designado como coordenador, através de um ponto de entrada único e não de apresentações separadas a cada autoridade nacional. Esse ponto de entrada é a plataforma de notificação única, que a ENISA cria, gere e mantém ao abrigo do artigo 16.º. Art. 14 · 16

O CSIRT que lhe compete decorre do seu estabelecimento principal na União ou, caso não esteja estabelecido na UE, do estabelecimento do seu mandatário. O CSIRT recetor difunde depois a notificação aos CSIRTs dos Estados-Membros em que o produto está disponível e, quando necessário, às autoridades de fiscalização do mercado. Art. 14(7) · 18

A lista de coordenadores foi publicada em 4 de setembro de 2026

Até 4 de setembro de 2026 não havia resposta publicada para a questão mais prática desta página: qual a equipa nacional que recebe efetivamente a sua notificação. A ENISA publicou agora uma lista dos CSIRT designados como coordenadores que indica um ou mais URL de contacto para cada um dos 27 Estados-Membros, e atribuiu-lhe nova data de 10 de setembro de 2026, pelo que deve verificar novamente a sua linha antes de confiar numa cópia obtida anteriormente. A Irlanda remete para uma página do NCSC dedicada ao CRA; a Espanha indica duas vias distintas do INCIBE, uma para incidentes e outra para a coordenação de vulnerabilidades.

A lista indica quem é o coordenador de cada Estado-Membro. Não indica qual é o seu, e o critério do artigo 14(7) é mais restrito do que a maioria das organizações supõe. O seu estabelecimento principal é o Estado-Membro onde as decisões sobre a cibersegurança dos seus produtos com elementos digitais são tomadas predominantemente, que pode ser um local de desenvolvimento em vez de uma sede social ou da maior operação comercial. Quando tal não puder ser determinado, o critério supletivo é o Estado-Membro onde tem o maior número de trabalhadores na UE. Sem qualquer estabelecimento na UE, a ordem é a seguinte: o Estado-Membro onde o seu mandatário atua para o maior número de produtos, depois o importador que coloca mais produtos no mercado, depois o distribuidor que disponibiliza mais produtos e, por fim, o Estado-Membro com mais utilizadores. Uma vez que isto fixa o destinatário de todas as notificações futuras, defina-o antecipadamente, com apoio jurídico, e registe por escrito a fundamentação.

Existe apoio de ambos os lados. ENISA mantém um serviço de apoio, com especial atenção às PME, e os CSIRTs designados como coordenadores são igualmente obrigados a prestar apoio sobre os deveres do artigo 14.º. A ENISA introduz também as vulnerabilidades corrigidas na European Vulnerability Databasee publica de dois em dois anos um relatório técnico sobre tendências, devendo o primeiro surgir no prazo de 24 meses a contar do início das obrigações de notificação. Art. 17(6)

A difusão de uma vulnerabilidade notificada pode ser suspensa pelo CSIRT, mas não por si

O CSIRT destinatário pode adiar ou reter a divulgação subsequente por razões justificadas de cibersegurança, durante o período estritamente necessário; por exemplo, quando uma vulnerabilidade está abrangida por um procedimento de divulgação coordenada. A Comissão especificou as condições no Regulamento Delegado (UE) 2026/881, adotado em 11 de dezembro de 2025. Sempre que um CSIRT retiver uma notificação, tem de informar imediatamente a ENISA, apresentando uma justificação e uma indicação do momento em que procederá à difusão.

Além disso, em particularmente circunstâncias excecionais pode assinalar, na sua notificação de 72 horas, uma das condições restritas previstas no artigo 16(2) : que a exploração se limita ao Estado-Membro do seu CSIRT, que a difusão subsequente seria contrária aos interesses essenciais desse Estado-Membro ou que a difusão constitui um risco elevado e iminente de cibersegurança. Nesse caso, a ENISA recebe apenas informação limitada (que foi feita uma notificação, informação geral sobre o produto, a natureza geral da exploração e que foram invocados motivos de segurança) até que o CSIRT liberte a notificação completa.

05Registo na plataforma

As orientações da ENISA sobre o registo, com nova data de 10 de setembro de 2026, e as suas orientações sobre a interface, com nova data de 9 de setembro de 2026, mostram os ecrãs reais. O registo abriu com a plataforma em 11 de setembro de 2026, pelo que este é agora um percurso que pode efetivamente percorrer em vez de apenas ler sobre ele. Ainda assim, a ENISA pede que não se registe preventivamente, pela razão exposta abaixo, o que torna conhecer o percurso antecipadamente mais útil e não menos: a primeira vez que o percorrer poderá muito bem ser com um relógio de 24 horas a correr.

Designe duas pessoas antes de precisar delas

A plataforma atribui a cada fabricante dois tipos de conta de utilizador, e pode decidir hoje quem os ocupa. Um representante principal regista-se primeiro e cria o registo do fabricante na plataforma. Essa pessoa convida depois um representante secundário , que desempenha um papel de reserva junto do mesmo fabricante e pode apresentar notificações em seu nome. Ambos são pessoas nomeadas da sua empresa. Uma vez que a apresentação é manual, ter um único notificador designado que esteja de férias, a dormir ou que já tenha saído é um risco operacional real, pelo que o segundo lugar deve ser tratado como necessário e não como opcional.

O EU Login é a credencial, e ambas as pessoas podem criá-la hoje

As contas da plataforma são autenticadas através do EU Login, o serviço de autenticação partilhado da Comissão Europeia utilizado nos seus sistemas em linha. Crie uma para o representante principal e outra para o secundário em ecas.ec.europa.eu, utilizando endereços de correio eletrónico profissionais que ainda existam daqui a um ano. A autenticação multifator é obrigatória: a ENISA exige MFA na conta EU Login antes do primeiro acesso à plataforma, pelo que, se as suas pessoas já tiverem contas EU Login simples, peça-lhes que ativem a MFA agora e não durante um incidente. As contas EU Login são pessoais, e a ENISA não opera qualquer autenticação empresarial distinta por cima delas. A Comissão explica o que é o EU Login, e como se insere no seu quadro de identidade mais amplo, nas suas páginas sobre identidade digital de confiança .

O percurso de registo

No primeiro acesso à plataforma seleciona o seu papel, escolhe numa lista pendente o seu CSIRT designado a partir de uma lista pendente, autentique-se através do EU Login, leia e aceite o acordo jurídico, confirme os seus dados pessoais pré-preenchidos (nome próprio, apelido, correio eletrónico, denominação legal) e introduza depois a denominação, o endereço e as informações adicionais do fabricante. A omissão de um campo obrigatório do fabricante bloqueia o fluxo. Na conclusão, o estado da sua conta é "Active" e assume a função "AR Primary User" e recebe uma mensagem de correio eletrónico de confirmação, sendo a entidade do fabricante criada na plataforma.

O secundário adere por convite por correio eletrónico do utilizador principal, confirma os dados pessoais e do fabricante pré-preenchidos e fica registado na função "AR Backup User" relativamente ao mesmo fabricante. Esse convite expira após 7 dias, após o que o registo é assinalado como "Invitation Expired" e é necessário enviar um novo. Configure a conta de reserva na mesma sessão em que configura a principal; um convite caducado descoberto a meio de um incidente é um problema evitável.

O CSIRT verifica manualmente o seu representante, mas isso não o impede de apresentar notificações

Alguém tem de confirmar que uma determinada pessoa pode efetivamente notificar em nome de um determinado fabricante, e essa verificação cabe ao CSIRT designado como coordenador, que a ENISA abrevia agora como CDaC. É um passo manual, o procedimento varia entre CSIRT e cada CSIRT define a sua própria abordagem. Fundamentalmente, ocorre depois do seu primeiro acesso à plataforma e decorre em paralelo com a sua notificação. Na sua atualização de 3 de agosto de 2026 a ENISA colocou a questão fora de dúvida: a validação pelo CDaC não é um requisito prévio para o cumprimento da obrigação de notificação do CRA, e não afeta a sua capacidade de apresentar notificações. Uma conta não validada pode ainda assim apresentar a notificação dentro do prazo de 24 horas.

É também por isso que a ENISA aconselha a registar-se e a iniciar a validação apenas quando tiver efetivamente de apresentar uma notificação, em vez de pré-registar todo o mercado e submergir os CSIRTs em verificações especulativas. A preparação a fazer com antecedência são as contas EU Login e a decisão sobre quem ocupa os dois lugares, e não o registo na plataforma propriamente dito.

Uma conta pode deter vários fabricantes

As mesmas orientações definem a gestão corrente dos dois lugares. Um mandatário principal convida um suplente através do endereço de correio eletrónico, o que cria um registo assinalado como "Pending Invitation" sem qualquer função até ser aceite. Um mandatário secundário pode pedir a promoção a principal, pedido que é submetido à apreciação do CDaC. A ENISA formalizou este ponto em 17 de setembro de 2026, assinalando a pergunta 9 das FAQ como «[ATUALIZADA]» para declarar que um AR secundário «não tem as mesmas permissões administrativas que o AR principal, mas pode reivindicar o papel de AR principal, sujeito a análise e aprovação do CSIRT designado». Qualquer um deles pode remover uma associação, que passa então a estar assinalada como "Deleted". E uma única conta pode ter associações com vários fabricantes, cada uma adicionada através de Association Management e cada uma verificada separadamente.

Este último ponto é relevante para grupos com várias entidades fabricantes e para empresas que atuam ao abrigo do artigo 18.º em nome de fabricantes estabelecidos fora da UE. É também onde a armadilha de nomenclatura descrita abaixo mais penaliza.

06Apresentar uma notificação

A notificação é feita a partir de um painel. Cria uma notificação e depois acrescenta ao mesmo registo em cada fase, em vez de apresentar três elementos separados. Cada fase tem o seu próprio separador e cada uma pode ser primeiro guardada como rascunho. O painel pode ser pesquisado por ID da notificação, fabricante ou título, ordenado por título ou última atualização, e filtrado por Estado-Membro, tipo de apresentação ou pelo indicador Action Required .

• Aviso prévioInicie uma nova notificação a partir do painel, preencha os campos obrigatórios e selecione um fabricante existente ou acrescente um. Após a apresentação, fica acessível ao seu CSIRT designado e, automaticamente, à ENISA. As confirmações por correio eletrónico e por alerta são enviadas ao CSIRT, à ENISA e a todos os mandatários registados para esse fabricante, não apenas à pessoa que a apresentou.
• 72 horasSó fica disponível quando já existe um aviso prévio. Abra a mesma notificação e preencha o separador das 72 horas. A ENISA recebe-a automaticamente, salvo se invoque as condições do artigo 16(2), caso em que o registo é assinalado com "72h Submitted under PEC" e a visão da ENISA fica limitada até que o CSIRT a liberte.
• Relatório finalApenas disponível depois de existirem ambas as fases anteriores. A ENISA recebe-o automaticamente, salvo se tiverem sido invocadas as condições do artigo 16(2).

O que é obrigatório, e quando

A ENISA publicou quais os campos obrigatórios em cada fase. O quadro corrige de forma útil um pressuposto generalizado: o aviso prévio de 24 horas é um alerta, não uma investigação.

• Às 24 horas; o tipo e o nível da notificação, o nome do fabricante ou do responsável, o produto e um título. No caso dos incidentes, se há suspeita de atos ilícitos ou maliciosos. Os Estados-Membros em que o produto está disponível só são exigidos se já dispuser dessa informação.
• Às 72 horas; a natureza geral da vulnerabilidade e da exploração, as medidas corretivas ou de atenuação adotadas e as medidas que os utilizadores podem tomar. No caso dos incidentes, quando foi detetado e quando ocorreu, mais uma avaliação inicial. É aqui que se assinala a sensibilidade.
• No relatório final; a descrição completa, a gravidade e o impacto, a data em que uma medida corretiva ficou disponível e o detalhe da atualização de segurança. No caso dos incidentes, a provável causa de origem e as medidas de atenuação em curso.

Entre os campos facultativos que vale a pena registar mesmo assim contam-se o CVE ID e o EUVD ID, ambos disponíveis desde a primeira fase.

Cada campo tem um limite de carateres, e um deles é muito curto

O Glossário SRP da ENISA, dimensionado pela primeira vez na versão 1.1 de 5 de setembro de 2026 e agora na versão 1.3 de 10 de setembro de 2026, é o documento da ENISA que publica a dimensão de cada caixa. Escreva os seus modelos internos de acordo com estes limites, em vez de os descobrir às duas da manhã:

• 4000 carateres para os campos descritivos: o resumo, a informação geral sobre a vulnerabilidade ou o incidente, as medidas corretivas que os utilizadores podem tomar, as descrições completas da gravidade e do impacto, a avaliação inicial e, para os incidentes, as medidas de mitigação aplicadas e em curso.
• 2000 carateres para as medidas corretivas ou de mitigação que já tenha tomado, e para o detalhe da atualização de segurança ou da medida corretiva no relatório final.
• 800 carateres para a justificação em texto livre que acompanha um pedido PEC na notificação de vulnerabilidade de 72 horas.
• 255 carateres para o título, o nome do produto, o intervalo de versões do produto, o nome do componente, o vetor de ataque, a justificação da sensibilidade e a provável causa de raiz.
• 100 carateres para o agente malicioso que explorou a vulnerabilidade. Isso corresponde a cerca de uma linha, pelo que deve prever nomear o agente ou remeter para uma referência de indicador, em vez de descrever a campanha.

O glossário confirma ainda uma pequena comodidade: o campo Estados-Membros onde o produto está disponível surge pré-preenchido com o seu próprio CSIRT coordenador, cabendo-lhe acrescentar os restantes mercados.

A edição, e o ponto sem retorno

Uma notificação apresentada pode ser atualizada, e a plataforma envia automaticamente um alerta e uma mensagem de correio eletrónico ao seu CSIRT, à ENISA e a quaisquer CSIRTs que já a tenham recebido por difusão. Aplicam-se dois limites: uma notificação encerrada não pode ser atualizada e o registo torna-se não editável assim que o relatório final é apresentado.

Vigie o separador de alertas, incluindo ao fim de semana

Cada conta tem um separador Alerts com código de cores: os alertas não lidos são azul-claros e ficam cinzentos depois de abertos, e os alertas vermelhos surgem apenas quando aconteceu algo excecional. O exemplo dado pela ENISA é o de um CSIRT designado que invalidou uma apresentação. A apresentação não é, portanto, o fim da troca, e nenhum prazo do artigo 14.º se altera pelo facto de uma notificação lhe ter sido devolvida. Quem vigia esse separador tem de o fazer também fora do horário de trabalho, o que constitui mais um argumento a favor de uma caixa de correio de equipa monitorizada por trás dos dois lugares, em vez de dois endereços pessoais.

O contador de 72 horas da plataforma não conta a partir do conhecimento

As FAQ revelam como os contadores no ecrã se comportam efetivamente, e não acompanham o prazo legal. A ENISA atualizou as FAQ em 10 de setembro de 2026, no dia anterior à abertura, e manteve esta resposta, pelo que o comportamento aqui descrito é o comportamento que entrou efetivamente em serviço. Na versão atual, o contador de 72 horas apresenta uma data-limite de 48 horas após a apresentação do relatório de 24 horas, e não de 72 horas após ter tomado conhecimento. A ENISA afirma claramente que uma notificação pode, por isso, surgir como em atraso antes de terem decorrido 72 horas desde o conhecimento, e que a lógica será alterada numa versão posterior para contar a partir do campo «data e hora em que tomou conhecimento», tanto para vulnerabilidades como para incidentes.

Os contadores do relatório final diferem novamente. No caso de um incidente grave o contador mostra um mês após a notificação de 72 horas. No caso de uma vulnerabilidade ativamente explorada não existe qualquer contador, porque o prazo depende do momento em que uma medida corretiva fica disponível, o que a plataforma não pode saber.

No lançamento, a plataforma não regista quando tomou conhecimento

Em 5 de setembro de 2026 a ENISA substituiu o seu Glossário SRP campo a campo pela versão 1.1, e duas notas de rodapé nele contidas importam mais do que tudo o resto nesta página. Para uma vulnerabilidade ativamente explorada, o campo Date/time when you become aware tem a nota de que estará disponível na próxima versão da plataforma. Para um incidente grave, a nota indica que, na versão atual, o campo equivalente se designa Date/time the incident was detected.

Colocado ao lado da lógica dos contadores acima, isso fecha um círculo. As FAQ diziam que o contador de 72 horas seria corrigido assim que chegasse o campo de tomada de conhecimento; o glossário dizia que o campo chega numa versão posterior. Nenhum dos dois se moveu antes da abertura: a ENISA reviu novamente o glossário para a versão 1.3 em 10 de setembro de 2026 e deixou ambas as notas de rodapé intactas. Assim, desde o primeiro dia a plataforma não capta qualquer momento de tomada de conhecimento para vulnerabilidades e, para incidentes, capta o momento da deteção, que não é o momento da tomada de conhecimento.

07O que pode fazer hoje

Cumprir uma janela de 24 horas é um problema operacional, não burocrático. Agora que a plataforma está aberta, a lista abaixo já não é preparação para um acontecimento futuro; o dever está a correr, e tudo o que aqui não tiver feito é uma exposição e não um plano.

• Crie as suas contas EU Login, com a MFA ativada. Para o notificador principal e pelo menos um suplente. Demora minutos em ecas.ec.europa.eu, e a plataforma não deixa entrar ninguém sem autenticação multifator, pelo que ativá-la faz parte da tarefa e não é um aperfeiçoamento dela.
• Identifique o seu CSIRT designado. A ENISA publicou a lista de coordenadores para os 27 Estados-Membros em 4 de setembro de 2026, pelo que esta é agora uma tarefa que pode concluir. Aplique o critério de estabelecimento principal do artigo 14(7), escolha a sua linha e registe por escrito a fundamentação.
• Construa internamente o formulário de 24 horas. Um modelo curto que corresponda aos campos obrigatórios do aviso prévio da ENISA, para que a sua primeira notificação real seja uma transcrição e não uma redação. Guarde-o num local que ambos os mandatários possam abrir, porque os rascunhos na plataforma só são visíveis para quem os criou.
• Nomeie as pessoas, incluindo fora de horas. Decida quem avalia que há lugar a notificação, quem a redige e quem a apresenta. Como não existe API, o último passo é uma pessoa concreta diante de um teclado.
• Mantenha um SBOM rigoroso. Não é possível notificar sobre um componente que não sabia ter incluído. Mantenha uma lista de materiais de software e conserve-a atualizada à medida que as versões mudam.
• Monitorize-a continuamente. Compare os seus componentes com fontes de vulnerabilidades conhecidas, para que uma falha ativamente explorada apareça em horas e não em semanas. O nosso SBOM e analisador de vulnerabilidades acompanha a sua lista de materiais face à NVD e à base de dados de vulnerabilidades da UE (EUVD).
• Confirme o que está efetivamente abrangido. A fase das 72 horas pede o tipo de produto e a categoria do anexo III ou IV, pelo que deve resolver a classificação antes de dela precisar. A ferramenta de classificação responde a essa questão, tal como a matriz de conformidade associa a notificação às obrigações mais amplas de gestão de vulnerabilidades do Anexo I em que se insere.
• Decida quem lê o separador de alertas fora do horário de trabalho. Um CSIRT designado pode invalidar uma apresentação, e o alerta que o comunica chega à plataforma e não apenas à sua caixa de entrada. Coloque uma caixa de correio monitorizada por trás dos dois lugares de mandatário.
• Não confie na contagem decrescente da plataforma. Registe você mesmo a hora do seu conhecimento. O contador de 72 horas no ecrã corre a partir da apresentação do relatório de 24 horas, e não do conhecimento, pelo que pode assinalar uma notificação como em atraso antes de o prazo legal ter terminado.
• Read the AR User Manual, and watch the tutorial video. ENISA published the manual at launch and added the AR User Tutorial Video within days, so between the two, plus the guidance pages, you have the fullest available description of the live platform.
• Confirme que escolheu o coordenador certo antes de apresentar. A ENISA avisa agora que selecionar o CSIRT designado como coordenador errado pode levar à invalidação da notificação, obrigando-o a apresentá-la de novo ao correto com o relógio ainda a correr.

08Acompanhe na fonte

Esta página reflete a situação em 11 de setembro de 2026, o dia em que a plataforma abriu. Continuará a mudar, e a ENISA edita as suas páginas discretamente em vez de anunciar cada alteração. Na semana anterior ao lançamento, as FAQ foram reescritas em 4 de setembro de 2026 e novamente atualizadas em 10 de setembro de 2026, a lista de coordenadores surgiu em 4 de setembro de 2026 e recebeu nova data em 10 de setembro de 2026, o glossário chegou à versão 1.1 em 5 de setembro de 2026 e à versão 1.3 em 10 de setembro de 2026, as orientações sobre circunstâncias particularmente excecionais chegaram em 9 de setembro de 2026, e o AR User Manual e os termos e condições da plataforma foram publicados em 10 de setembro de 2026. Desde o lançamento, as FAQ foram novamente atualizadas em 12 de setembro de 2026 (o vídeo tutorial para utilizadores AR entrou no ar e a ficha informativa da SRP passou a estar disponível em mais nove línguas) e em 17 de setembro de 2026, quando a pergunta 9 foi assinalada como «[ATUALIZADA]» para documentar que um AR secundário pode reivindicar o papel de AR principal, sujeito a análise do CDaC. Para questões de apoio, a ENISA publica um endereço de helpdesk na página do hub, cra-srp-helpdesk [at] enisa.europa.eu. Estas são as fontes primárias; tudo o que acima ficou dito é a nossa leitura delas.

• ENISA · A própria plataforma de notificação única (em serviço desde 11 de setembro de 2026); selecione o papel Assigned Representative e inicie sessão através do EU Login com autenticação multifator. É aqui que as notificações são apresentadas.portal.cra-srp.enisa.europa.eu
• ENISA · plataforma de notificação única; a página do hub, com a ficha informativa, o manual do utilizador, o endereço de helpdesk e as ligações a todas as páginas de orientação.enisa.europa.eu/topics/product-security/single-reporting-platform-srp
• ENISA · Perguntas frequentes sobre a SRP (atualizadas em 10 de setembro de 2026); base jurídica, prazos, encaminhamento, a tabela de campos, a lógica dos contadores, o que fazer durante uma interrupção e o endereço da plataforma. Reescritas em 4 de setembro e alargadas no dia anterior ao lançamento. A mais atual das páginas da SRP da ENISA, e aquela a preferir quando estiverem em conflito.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions
• ENISA · CRA SRP AR User Manual (10 de setembro de 2026); o manual do dia do lançamento para os Assigned Representatives, e a descrição única mais completa da plataforma tal como efetivamente abriu.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-ar-user-manual
• ENISA · Lista dos CSIRT designados como coordenadores (publicada em 4 de setembro de 2026, atualizada em 10 de setembro de 2026); pontos de contacto para os 27 Estados-Membros. Identifique a sua linha utilizando o critério do artigo 14(7) na secção 04.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/list-of-csirts-designated-as-coordinators
• ENISA · Glossário SRP do CRA (versão 1.3, 10 de setembro de 2026); orientação campo a campo sobre o que significa cada campo de notificação, como o preencher, o formato esperado, o seu limite de carateres e a fase em que se aplica. Atenção ao endereço: a ENISA transferiu o glossário para um glossary2 URL e o anterior continua ligado a partir de algumas das suas próprias páginas, pelo que deve verificar a linha da versão no topo antes de confiar numa cópia.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-glossary2
• ENISA · orientações sobre o registo de utilizadores na SRP; o percurso de registo passo a passo para utilizadores principais e de reserva, com capturas de ecrã da interface.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-user-registration
• ENISA · orientações sobre a apresentação de notificações na SRP; como são apresentados e atualizados o aviso prévio, a notificação de 72 horas e o relatório final, e o que cada estado desencadeia.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-notification-submission-and-update
• ENISA · Orientações sobre as funções da interface da SRP (9 de setembro de 2026); definições, associações a fabricantes, o painel e o separador de alertas. Recebeu nova data no próprio dia do lançamento e concorda agora com as FAQ em que uma associação não verificada pode apresentar até 20 notificações.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-interface-functions
• ENISA · Termos e condições da CRA SRP (versão 1.0, 10 de setembro de 2026); os termos que aceita quando se regista na plataforma, publicados no dia anterior à sua abertura.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-single-reporting-platform-terms-and-conditions
• ENISA · Orientações da SRP sobre circunstâncias particularmente excecionais (9 de setembro de 2026); quando se aplica a PEC, o interruptor e os motivos de adiamento no formulário de 72 horas e o que o CSIRT coordenador faz com a justificação. A quinta página de orientações e a única que trata diretamente da PEC.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-particular-exceptional-circumstances-pec
• Comissão Europeia · obrigações de notificação do CRA; a página de política, incluindo as FAQ sobre a aplicação do CRA, cuja secção 5 trata da notificação. A Comissão atualizou esta página em 11 de setembro de 2026 para confirmar que a plataforma já está operacional, e o documento de FAQ separado da Comissão foi atualizado pela última vez em 4 de setembro de 2026.digital-strategy.ec.europa.eu/en/policies/cra-reporting
• Comissão Europeia · orientações sobre a aplicação do CRA (27 de julho de 2026); o ponto 9.1 expõe as obrigações de notificação dos fabricantes e dos responsáveis por software de fonte aberta. O nosso resumo das orientações cobre o resto.digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation
• EU Login; crie a conta que a plataforma utiliza e ative nela a autenticação multifator. Faça-o já.ecas.ec.europa.eu/cas/login

Quanto ao texto vinculativo, os artigos 14.º a 17.º definem o ecossistema de notificação e o artigo 16.º cria a plataforma; leia-os no nosso leitor do regulamento. As datas marcantes são acompanhadas na página ponto de situação .

09Questões comuns