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)
Se uma fraqueza de segurança no seu produto estiver a ser ativamente explorada, ou um incidente de segurança o tiver afetado gravemente, o prazo do artigo 14.º começa a contar. Tudo o resto permanece no âmbito da sua gestão quotidiana de vulnerabilidades.
Uma vulnerabilidade de cuja exploração ativa já tinha conhecimento antes de a obrigação de notificação ser aplicável, em 11 de setembro de 2026, não tem de ser notificada. O dever fixa-se no momento em que tomar conhecimento, pelo que abrange aquilo de que toma conhecimento a partir dessa data e nada anterior.
É neste ponto que a maioria se engana, pelo que vale a pena ser exato. Artigo 69(2) estabelece a regra transitória geral: os produtos colocados no mercado antes de 11 de dezembro de 2027 só ficam abrangidos pelo Regulamento se forem substancialmente modificados a partir dessa data. Lida isoladamente, esta regra sugere que o catálogo existente fica intocado.
Artigo 69(3) retira-lhe logo de seguida o artigo 14.º. Por derrogação expressa, as obrigações de notificação aplicam-se a todos os produtos com elementos digitais abrangidos pelo Regulamento que tenham sido colocados no mercado antes de 11 de dezembro de 2027, sejam ou não alguma vez modificados.
As duas regras correm, portanto, em eixos diferentes. Um produto que vendeu em 2025 pode nunca necessitar de marcação CE ao abrigo do CRA e, ainda assim, se uma vulnerabilidade nele existente for ativamente explorada e disso tomar conhecimento em 11 de setembro de 2026 ou depois, é notificável. A sua base instalada está abrangida pela obrigação de notificação mesmo quando está fora do âmbito dos requisitos aplicáveis aos produtos. A Comissão chega à mesma conclusão no ponto 5.3 das suas FAQ sobre a aplicação do CRA. Art. 69(2)–(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 planeou que a plataforma de notificação única esteja operacional nessa mesma data. Art. 71
A plataforma ainda não está em serviço e o respetivo URL público não foi publicado. A ENISA indica que este será comunicado na sua página sobre a plataforma de notificação única antes da entrada em serviço. Antes disso, estão previstos testes de utilizador e de segurança, com a participação da rede de CSIRTs.
A ENISA publicou, no entanto, uma ficha informativa, umas FAQ alargadas e duas páginas de orientações passo a passo sobre o registo e a apresentação de notificações, todas atualizadas pela última vez em 31 de julho de 2026. Estão ainda por surgir vídeos instrutivos curtos e um webinário duas semanas antes da entrada em serviço. A ENISA assinala que as orientações publicadas podem ser alteradas.
Faltam ainda dois elementos: a lista dos CSIRTs nacionais designados como coordenadores, que a ENISA diz que disponibilizará numa fase posterior, e as normas harmonizadas que sustentam o tratamento de vulnerabilidades, esperadas por volta de 30 de agosto de 2026 e ainda não citadas no Jornal Oficial.
Ao contrário da marcação CE, que se conclui uma vez antes de colocar um produto no mercado, a notificação é um dever permanente e contínuo que começa em setembro de 2026 e pode ser desencadeado a qualquer momento a partir daí. Estar preparado não é um projeto pontual. Construa já o processo interno de deteção e notificação; o dever aplica-se a partir de 11 de setembro de 2026, estejam ou não as ferramentas concluídas.
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
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 recetor pode atrasar ou não efetuar a difusão subsequente por motivos justificados de cibersegurança, pelo período estritamente necessário; por exemplo, quando uma vulnerabilidade está integrada num procedimento de divulgação coordenada. A Comissão especificou as condições num ato delegado 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.
Nenhum dos mecanismos suspende o seu prazo. Não pode adiar a apresentação; os prazos de 24 horas, 72 horas e do relatório final contam-se a partir do momento em que toma conhecimento. O que pode fazer é assinalar a sensibilidade, o que limita quem vê o conteúdo. A decisão de reter a difusão cabe ao CSIRT recetor.
05Registo na plataforma
As orientações da ENISA de 31 de julho de 2026 são o primeiro material que mostra os ecrãs reais. Só poderá registar-se na própria plataforma quando esta entrar em serviço, mas pode desde já decidir quem ficará com as contas e preparar as respetivas credenciais, e convém conhecer o percurso antes de o enfrentar com um prazo 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. A ENISA indica que a conta pode ser criada com antecedência, e esta é a coisa mais útil que pode fazer neste momento. 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 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 , autentica-se através do EU Login, lê e aceita o acordo jurídico, confirma os seus dados pessoais pré-preenchidos (nome próprio, apelido, correio eletrónico, denominação legal) e introduz depois o nome, o endereço e as informações adicionais do fabricante. A omissão de um campo obrigatório do fabricante bloqueia o percurso. Concluído o processo, a sua conta fica ativa no papel "AR Active", recebe uma mensagem de confirmação e a entidade do fabricante é criada na plataforma.
O secundário adere por convite por correio eletrónico do representante principal, confirma os dados pessoais e do fabricante pré-preenchidos e é registado como utilizador de reserva junto do mesmo fabricante. Esse convite caduca ao fim de 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 determinada pessoa pode efetivamente notificar em nome de determinado fabricante, e essa verificação cabe ao CSIRT designado como coordenador. É um passo manual, o procedimento varia entre CSIRTs e cada CSIRT define a sua própria abordagem. O ponto essencial é que ocorre depois do seu primeiro acesso à plataforma e decorre em paralelo com a sua notificação: a ENISA indica que a validação não afeta a sua capacidade de apresentar notificações. Uma conta não validada pode ainda assim apresentar notificações 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.
As orientações da ENISA estão escritas para "Assigned Representatives" (AR), com utilizadores principais e utilizadores de reserva. Trata-se de uma função de conta na plataforma. Este não é o mandatário designado por mandato escrito ao abrigo do artigo 18.º do CRA. Pode ter o primeiro sem ter o segundo. Mantenha os dois separados no seu procedimento interno, sob pena de acabar a discutir uma designação jurídica quando tudo o que precisa é de um segundo início de sessão.
06Apresentar uma notificação
A notificação faz-se a partir de um painel. Cria uma notificação e depois acrescenta informação ao mesmo registo em cada fase, em vez de apresentar três documentos separados. Cada fase tem o seu separador e cada uma pode ser primeiro guardada como rascunho; os rascunhos são visíveis apenas para si.
- Aviso prévioInicie uma nova notificação a partir do painel, preencha os campos obrigatórios e selecione um fabricante existente ou acrescente um. Ao ser apresentada, é enviada ao seu CSIRT designado e, automaticamente, à ENISA. As confirmações por correio eletrónico e por alerta são enviadas a si, ao CSIRT e à ENISA.
- 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 invocar as condições do artigo 16(2), caso em que o registo é assinalado e a visão da ENISA fica limitada até que o CSIRT o liberte.
- Relatório finalSó fica disponível quando já existem as duas fases anteriores. Os restantes CSIRTs interessados só recebem o relatório final depois de o seu CSIRT coordenador o difundir manualmente.
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.
A edição, e o ponto sem retorno
Uma notificação apresentada pode ser atualizada, e a plataforma alerta automaticamente o seu CSIRT, a ENISA e 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.
A ENISA indica que não será disponibilizada nesta fase qualquer interface de programação de aplicações. Pode automatizar internamente a deteção, a triagem e a redação, mas a apresentação em si é uma pessoa a preencher um formulário no navegador. Planeie deliberadamente essa passagem de testemunho e assegure que mais do que uma pessoa a consegue executar fora de horas e ao fim de semana.
A plataforma aceitará também notificações voluntárias de vulnerabilidades, ciberameaças, incidentes e quase-incidentes, de qualquer pessoa singular ou coletiva e não apenas dos fabricantes. A ENISA afirma que esta funcionalidade é ativada depois do 11 de setembro de 2026, pelo que não é uma via para um ensaio sem risco antes do prazo.
07O que pode fazer hoje
Cumprir um prazo de 24 horas é um problema operacional, não burocrático, e quase toda a preparação já é possível. Nada do que se segue depende de a plataforma estar em serviço.
- Crie as suas contas EU Login. Para o notificador principal e pelo menos um suplente. Demora minutos em ecas.ec.europa.eu e elimina um passo que não quer descobrir a meio de um incidente.
- Identifique o seu CSIRT designado. Decorre do seu estabelecimento principal na União ou do do seu mandatário, caso esteja estabelecido fora da UE. A lista completa de coordenadores da ENISA ainda está por publicar, pelo que deve registar já o seu raciocínio e confirmá-lo com a lista quando esta surgir.
- 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 apresentação real seja uma transcrição e não uma redação.
- 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.
- Marque o webinário na agenda. A ENISA tenciona realizar um duas semanas antes da entrada em serviço da plataforma e publicar vídeos instrutivos curtos mais perto do lançamento.
08Acompanhe na fonte
Esta página reflete a situação em 6 de agosto de 2026. A plataforma continua a evoluir e a ENISA altera as suas páginas discretamente, em vez de anunciar cada mudança, pelo que vale a pena verificar diretamente as datas de "last updated" nas páginas abaixo. Estas são as fontes primárias; tudo o que fica acima é a nossa leitura das mesmas.
- ENISA · plataforma de notificação única; a página central, com a ficha informativa e umas FAQ detalhadas sobre a base jurídica, os prazos, o encaminhamento, o quadro de campos e a segurança da plataforma. É onde será anunciado o URL público.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp
- 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/cra-srp-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/cra-srp-ar-notification-submission-and-update
- 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.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 irá utilizar. 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
O que devo notificar ao abrigo do CRA e com que rapidez?
Vulnerabilidades ativamente exploradas e incidentes graves que afetem a segurança do seu produto. Um aviso prévio no prazo de 24 horas a contar do momento em que toma conhecimento, uma notificação mais completa no prazo de 72 horas e um relatório final no prazo de 14 dias a contar da disponibilização de uma medida corretiva, no caso de uma vulnerabilidade, ou no prazo de um mês a contar da notificação de 72 horas, no caso de um incidente grave. Art. 14
Quando é que as obrigações de notificação têm início?
11 de setembro de 2026; 21 meses após a entrada em vigor do Ato, muito antes da aplicação plena em 11 de dezembro de 2027.
A quem notifico?
A ENISA e o CSIRT nacional designado como coordenador, através da plataforma de notificação única criada ao abrigo do artigo 16.º. O seu CSIRT decorre do seu estabelecimento principal na União ou do do seu mandatário, caso não esteja estabelecido na UE.
Tenho de notificar todos os erros ou vulnerabilidades?
Não. Apenas as vulnerabilidades ativamente exploradas e os incidentes graves são objeto de notificação. As vulnerabilidades que encontra e corrige antes de serem exploradas são geridas através do seu processo ordinário de gestão de vulnerabilidades.
A plataforma de notificação única da ENISA já está disponível?
Não, em 6 de agosto de 2026. A plataforma não está em serviço e o respetivo URL público não foi publicado; a ENISA anunciá-lo-á na sua página da SRP antes da entrada em serviço. Está previsto que fique operacional até 11 de setembro de 2026, com testes de utilizador e de segurança antes disso.
Posso registar-me ou preparar alguma coisa desde já?
Sim, e deve fazê-lo. Crie as contas EU Login que a plataforma irá utilizar, para um notificador principal e um suplente. Só poderá registar-se na própria plataforma quando esta entrar em serviço, e a ENISA aconselha a iniciar o registo na plataforma apenas quando tiver efetivamente de apresentar uma notificação, porque o CSIRT coordenador valida a conta após o primeiro acesso e não antes dele. Essa validação não bloqueia a apresentação.
Posso apresentar notificações através de uma API?
Não. A ENISA indica que não será disponibilizada nesta fase qualquer interface de programação de aplicações. Pode automatizar a deteção e a redação internas, mas a apresentação é uma pessoa a preencher um formulário no navegador.
O que tem afinal de conter o aviso prévio de 24 horas?
Menos do que a maioria espera. Os campos obrigatórios são o tipo e o nível da notificação, o nome do fabricante ou do responsável, o produto, um título e, no caso dos incidentes, se há suspeita de atos ilícitos ou maliciosos. A análise substantiva é devida às 72 horas, não no primeiro dia.
Já existe um formato padrão ou modelo para a notificação?
Os campos de dados estão publicados. As FAQ da ENISA indicam quais são obrigatórios nas fases de 24 horas, 72 horas e do relatório final, pelo que pode construir hoje um modelo interno correspondente. A Comissão pode ainda especificar melhor o formato e o procedimento através de atos de execução.
Posso adiar uma notificação se a divulgação for arriscada?
A apresentação, não. Os prazos de 24 horas, 72 horas e do relatório final contam-se a partir do momento em que toma conhecimento e nada os suspende. Pode assinalar a sensibilidade: ao abrigo do artigo 16(2) pode marcar condições restritas que limitam o que a ENISA vê até o CSIRT libertar a notificação completa. A decisão de adiar a difusão subsequente cabe ao CSIRT recetor, nos termos do ato delegado adotado em 11 de dezembro de 2025.
Tenho de notificar uma exploração de que já tinha conhecimento antes de setembro de 2026?
Não. A obrigação aplica-se a partir do momento em que toma conhecimento e não abrange vulnerabilidades de cuja exploração ativa já tinha conhecimento antes de 11 de setembro de 2026.
A notificação aplica-se a produtos que coloquei no mercado há anos?
Sim. O artigo 69(2) determina que os produtos colocados no mercado antes de 11 de dezembro de 2027 só ficam abrangidos pelo Regulamento se forem substancialmente modificados a partir dessa data, mas o artigo 69(3) derroga expressamente essa regra quanto ao artigo 14.º: as obrigações de notificação aplicam-se a todos os produtos abrangidos que tenham sido colocados no mercado antes de 11 de dezembro de 2027, modificados ou não. Um produto pode, por isso, estar fora do âmbito dos requisitos de produto do CRA e continuar abrangido pela obrigação de notificação. Art. 69(2)–(3)
Isto aplica-se aos projetos de fonte aberta?
Os responsáveis por software de fonte aberta têm obrigações de notificação na medida em que estejam envolvidos com produtos com elementos digitais, ao abrigo do artigo 24(3). As orientações da Comissão de 27 de julho de 2026 tratam a fonte aberta com mais pormenor.
Onde posso obter ajuda se for uma pequena empresa?
A 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 prevê ainda vídeos instrutivos e um webinário duas semanas antes da entrada em serviço da plataforma.