Para implementar os controlos de acesso da NIS2 na segurança da cadeia de abastecimento, é necessário mapear cada fornecedor direto e prestador de serviços para os sistemas, contas, privilégios, métodos de autenticação e registos de evidências que utiliza. Em seguida, devem aplicar-se o princípio do menor privilégio, a autenticação multifator (MFA) ou a autenticação contínua, sempre que adequado, controlos de contas privilegiadas, cláusulas contratuais, monitorização e revisões de acesso periódicas.
A segurança da cadeia de abastecimento da NIS2 não é um exercício de aquisições. Implica traduzir cada relação com fornecedores em controlos aplicáveis sobre contas, credenciais partilhadas, vias de acesso remoto, ações privilegiadas e logs.
De acordo com o relatório de 2025 da Verizon (Data Breach Investigations Report), o envolvimento de terceiros surgiu em 30 % das violações de dados analisadas. O DBIR de 2026 mostra a aceleração desta tendência: o envolvimento de terceiros surge agora em 48 % das violações de dados confirmadas, um aumento de 60 % face ao ano anterior. Nesta trajetória, a governação do acesso de fornecedores deixa de ser um risco de primeiro nível que se possa adiar.
O argumento financeiro é igualmente expressivo. IBM, no relatório Cost of a Data Breach Report 2025, situa o custo médio de um comprometimento da cadeia de abastecimento em 4,91 milhões de dólares, e estas violações demoram, no conjunto, 267 dias a identificar e a conter. O artigo 21.º da NIS2 e o Regulamento de Execução (UE) 2024/2690 fazem disto um mandato de gestão de identidades e acessos (IAM), e não uma questão de gestão de fornecedores.
A organização é responsável, do ponto de vista regulamentar, por cada via de acesso concedida a uma entidade externa.
Pontos principais
- A segurança da cadeia de abastecimento da NIS2 é um mandato de IAM, e não uma questão de gestão de fornecedores. O artigo 21.º, n.º 2, alínea d), torna a organização juridicamente responsável por cada via de acesso concedida a uma entidade externa, incluindo VPN, APIs, consolas de administração SaaS, pipelines CI/CD e ferramentas de suporte remoto.
- Os incidentes com origem em terceiros estão a acelerar. O DBIR 2026 da Verizon situa o envolvimento de terceiros em 48 % das violações de dados confirmadas, contra 30 % no ano anterior.
- As orientações de 2025 da ENISA exigem MFA de nível 1 para todo o acesso privilegiado de fornecedores. FIDO2 e WebAuthn são os únicos métodos aceitáveis para contas de fornecedores com acesso administrativo ou a sistemas de produção. O SMS OTP está sinalizado para abandono progressivo.
- As contas partilhadas de fornecedores são uma lacuna de conformidade. Contas nominais individuais, RBAC com menor privilégio e acesso privilegiado just-in-time são a base de referência, e não um reforço opcional.
- Os logs de auditoria são a evidência, não o plano de contingência. O prazo de 24 horas para o alerta precoce previsto no artigo 23.º não pode ser cumprido sem logs imutáveis que mostrem exatamente o que uma conta de fornecedor fez e quando.
- A revogação de acessos deve ser automática e associada aos eventos do ciclo de vida do contrato. Os pedidos manuais de desprovisionamento são demasiado lentos. Quando o contrato de um fornecedor termina, o acesso termina com ele.
- O registo de controlo de acesso de fornecedores é a unidade de responsabilização. Um registo por relação com fornecedor (via de acesso, tipo de identidade, nível de MFA, evidências), atualizado em cada ciclo de revisão.
O que a NIS2 exige dos controlos de acesso de fornecedores
Artigo 21.º da NIS2 exige que as entidades essenciais e importantes adotem medidas técnicas, operacionais e organizacionais adequadas e proporcionadas para gerir os riscos de cibersegurança. O artigo 21.º, n.º 2, enumera dez medidas mínimas. Cinco incidem diretamente na governação do acesso de fornecedores.
| Artigo 21.º, n.º 2, alínea | Requisito | Implicação para o acesso de fornecedores |
|---|---|---|
| (a) | Políticas de análise de risco e de segurança dos sistemas de informação | O risco do acesso de fornecedores deve ser avaliado e documentado como parte da postura de risco global da entidade |
| (d) | Segurança da cadeia de abastecimento, incluindo os aspetos de segurança relacionados com as relações com fornecedores diretos ou prestadores de serviços | Mapear cada fornecedor para os sistemas e as vias de acesso que utiliza; governar essas relações através de políticas e contratos |
| (e) | Segurança na aquisição, no desenvolvimento e na manutenção de redes e sistemas de informação, incluindo o tratamento de vulnerabilidades | Os sistemas, as integrações e os repositórios de código geridos por fornecedores estão abrangidos, incluindo pipelines CI/CD e APIs |
| (i) | Segurança dos recursos humanos, políticas de controlo de acesso e gestão de ativos | As contas nominais, as permissões baseadas em funções e as restrições de acesso ao nível dos ativos aplicam-se às identidades de fornecedores, e não apenas ao pessoal interno |
| (j) | Soluções de MFA ou de autenticação contínua, sempre que adequado | O acesso remoto, privilegiado e a sistemas de produção por parte de fornecedores exige MFA ou equivalente, proporcional ao risco |
A diretiva não impõe uma ferramenta única nem um método de MFA universal. Exige medidas adequadas e proporcionadas ao risco. No caso do acesso de fornecedores, isso significa identificar que utilizadores externos, contas de suporte, APIs e integrações podem chegar aos ativos críticos da organização, e aplicar depois controlos adequados à sensibilidade do que essas vias expõem.
O artigo 21.º, n.º 3, vai mais longe: as entidades devem ter em conta as vulnerabilidades específicas de cada fornecedor direto e prestador de serviços, bem como a qualidade global das suas práticas de cibersegurança. Isto faz da governação de identidades e acessos de fornecedores uma obrigação legal direta, e não uma recomendação de boas práticas.
O Regulamento de Execução (UE) 2024/2690 traduz os requisitos de alto nível do artigo 21.º em mais de 150 controlos de cibersegurança específicos. Para as relações com fornecedores, estabelece expectativas concretas em matéria de atribuição de acessos, gestão de contas privilegiadas e notificação de incidentes, deslocando a questão de conformidade de «existe uma política?» para «é possível provar que os controlos funcionam?»
ENISA, nas orientações técnicas de implementação de 2025, considera a política de segurança da cadeia de abastecimento, a política de controlo de acessos e as políticas de contas privilegiadas como políticas temáticas obrigatórias no quadro da NIS2.
Os 5 controlos de acesso essenciais para a conformidade da NIS2 na cadeia de abastecimento
Se um fornecedor tem acesso remoto ou privilegiado, a segurança da cadeia de abastecimento da NIS2 passa a ser um problema de controlo de identidades. A relação com o fornecedor cria uma via direta para as redes e os sistemas de informação da organização.
Aplicar um controlo de acesso baseado em funções (RBAC) rigoroso
Eliminar as contas partilhadas de fornecedores. Cada engenheiro do fornecedor que necessite de acesso a sistemas recebe uma conta nominal e individual, associada ao respetivo projeto. As contas genéricas de «fornecedor» impossibilitam a atribuição de responsabilidades durante um incidente, e essa atribuição é exatamente o que exige o requisito de alerta precoce em 24 horas do artigo 23.º.
Aplicar o princípio do menor privilégio ao nível das funções: os fornecedores recebem o acesso mínimo necessário para executar as tarefas contratadas, limitado a ativos específicos e não a segmentos amplos do sistema. Quando o âmbito do projeto muda, as permissões mudam com ele.
Implementar MFA de nível 1 para o acesso privilegiado
As orientações técnicas de 2025 da ENISA classificam a MFA em três níveis. Para qualquer fornecedor com acesso administrativo ou privilegiado, o nível 1 é a única opção aceitável.
| Nível de MFA da ENISA | Método de autenticação | Contexto do requisito da NIS2 |
|---|---|---|
| Nível 1 (mais forte) | FIDO2, WebAuthn, chaves de segurança de hardware | Obrigatório para todo o acesso privilegiado e administrativo de fornecedores. Resistente a phishing por conceção. |
| Nível 2 (intermédio) | Aplicações de autenticação TOTP, notificações push | Aceitável para contas de fornecedores padrão, sem privilégios elevados. |
| Nível 3 (fraco) | SMS OTP, OTP por e-mail | Sinalizado para abandono progressivo. Não cumpre os limiares mínimos para ambientes regulados. |
A implicação prática: se os engenheiros de suporte de um MSP se autenticam por SMS para aceder a sistemas de produção, existe uma lacuna de conformidade face às orientações atuais da ENISA. Os métodos de nível 1 são resistentes a phishing porque a credencial criptográfica está associada ao domínio específico, e um site de phishing não a consegue intercetar.
Implementar a gestão de acessos privilegiados (PAM) e o armazenamento de credenciais em cofre
O acesso just-in-time (JIT) é o modelo adequado para equipas de suporte de terceiros. Os privilégios elevados são concedidos para uma sessão definida, registados na íntegra e revogados automaticamente quando a sessão termina. Sem acesso permanente e sem contas privilegiadas persistentes que se acumulam ao longo de anos de relações com fornecedores.
Para as credenciais partilhadas que não podem ser eliminadas (contas break-glass de emergência, contas de serviço de sistemas legados, chaves de API partilhadas), deve utilizar-se um cofre de credenciais com permissões baseadas em funções e um registo de auditoria completo. Um gestor de palavras-passe empresarial pode centralizar as credenciais partilhadas de fornecedores, restringir o acesso por função e conservar os registos que um auditor irá solicitar.
Black Kite, no 2026 Supply Chain Vulnerability Report, concluiu que os atacantes exploram vulnerabilidades, em média, sete dias antes da divulgação pública, a partir da análise de mais de 48 000 CVE publicados em 2025. As credenciais de fornecedores de longa duração que permanecem em pipelines CI/CD ou em contas de integração são um convite permanente. Os tokens de API devem ser rodados segundo um calendário definido e revogados imediatamente quando a relação com o fornecedor termina.
Manter logs de auditoria imutáveis
O artigo 23.º estabelece prazos rigorosos de notificação de incidentes: um alerta precoce em 24 horas, uma notificação formal em 72 horas e um relatório final completo no prazo de um mês. Cumprir esses prazos sem logs de auditoria imutáveis não é realista. Os logs são a evidência: mostram exatamente o que uma conta de fornecedor fez, quando e a partir de onde.
Os logs devem ser resistentes a adulteração e conservados durante o tempo suficiente para apoiar tanto investigações internas como pedidos das autoridades de supervisão. No caso das contas de fornecedores, devem registar-se eventos de autenticação, escalonamentos de privilégios, atividade de sessão, alterações de configuração e acessos a dados sensíveis. Quando ocorre um incidente, a pergunta «a que teve acesso esta conta de fornecedor?» exige resposta em horas, e não em semanas.
Automatizar a revogação de credenciais
Associe o acesso dos fornecedores diretamente aos eventos do ciclo de vida do contrato. Quando um contrato com um fornecedor expira, é rescindido ou quando um engenheiro com conta nominal deixa a equipa do fornecedor, a revogação do acesso deve ser imediata e automática, sem depender de um pedido manual que alguém se lembre de registar.
Elaborar um registo de controlo de acesso de fornecedores
Um registo de controlo de acesso de fornecedores é o registo operacional que associa uma relação com um fornecedor a direitos de acesso específicos e às evidências de que esses direitos estão controlados. Um registo por relação com fornecedor. Esta é a unidade de responsabilização.
O registo responde às perguntas que um auditor, um regulador ou a própria equipa de resposta a incidentes irá colocar: quem tem acesso, a quê, por que via, com que autenticação e quem deu aprovação?
| Campo | O que registar | Exemplo |
|---|---|---|
| Fornecedor e responsável | Nome do fornecedor e responsável interno pelo negócio | Fornecedor de suporte cloud: operações de TI |
| Via de acesso | VPN, ZTNA, administração SaaS, API, repositório, suporte remoto | Conta VPN de fornecedor |
| Tipo de identidade | Utilizador nominal, conta partilhada, conta de serviço, token | Engenheiro de suporte com conta nominal |
| Controlo | Nível de MFA, aprovação PAM, limite de tempo, restrição de IP, acesso ao cofre | MFA de nível 1 e aprovação da sessão privilegiada |
| Evidências | Logs, revisão de acessos, cláusula contratual, pedido | Registo da revisão trimestral |
As orientações de 2025 da ENISA preveem que a política de segurança da cadeia de abastecimento rege as relações com fornecedores diretos e prestadores de serviços e identifica as funções dos fornecedores: fornecedor de TIC, prestador de serviços geridos (MSP), prestador de serviços de segurança geridos (MSSP) e fornecedor de cloud.
Os registos devem refletir estas distinções. O perfil de risco de um MSP com acesso privilegiado à infraestrutura difere significativamente do de um fornecedor SaaS com acesso de API só de leitura, e os controlos devem diferir em conformidade.
Como auditar o acesso atual de fornecedores
Deve começar-se por um mapeamento completo dos fornecedores. Listar todas as ligações externas: VPN, APIs, consolas de administração SaaS, ferramentas de suporte remoto, integrações CI/CD e acesso a repositórios. Para cada ligação, identificar o tipo de identidade, o método de autenticação, o nível de privilégio e o responsável interno pela relação.
Em seguida, deve percorrer-se esta lista de verificação prévia à auditoria do acesso de fornecedores (7 pontos):
- Todas as contas de fornecedores são nominais, sem credenciais genéricas partilhadas em uso para acesso privilegiado
- O nível de MFA corresponde à sensibilidade do acesso: nível 1 para acesso privilegiado, nível 2 no mínimo para acesso padrão
- Todas as contas de fornecedores são provisionadas através de controlos de diretório, com desprovisionamento automatizado
- Os contratos com fornecedores incluem requisitos de contas nominais, obrigações de MFA, notificação de violações em 24 horas, direitos de auditoria e divulgação de subcontratantes
- A PAM ou o registo de sessões abrange todas as sessões privilegiadas de fornecedores
- Os tokens de API e as credenciais de contas de serviço têm calendários de rotação definidos
- A cadência das revisões de acesso está documentada: trimestral para fornecedores críticos, anual para todos os outros e imediata após qualquer cessação ou incidente
Atualizar os contratos com fornecedores para incluir cláusulas explícitas de notificação de violações em 24 horas e direitos de auditoria, caso ainda não existam. As orientações de 2025 da ENISA indicam que os contratos ou SLAs devem abranger requisitos de cibersegurança, obrigações de notificação de incidentes, tratamento de vulnerabilidades, requisitos de subcontratação e obrigações de cessação.
O custo da não conformidade: coimas e responsabilidade pessoal
As entidades essenciais estão sujeitas a coimas máximas de até 10 milhões de euros ou 2 % do volume de negócios anual a nível mundial ao abrigo da NIS2, consoante o valor que for mais elevado. As entidades importantes estão sujeitas a coimas até 7 milhões de euros ou 1,4 % do volume de negócios. Trata-se de máximos administrativos (as autoridades aplicam o princípio da proporcionalidade), mas são o limite que a administração tem de compreender.
O artigo 20.º vai mais longe. Estabelece a responsabilização pessoal dos dirigentes de topo e dos órgãos de gestão. Os dirigentes podem ser objeto de proibições temporárias do exercício de funções de gestão se a respetiva organização for considerada gravemente negligente nas suas obrigações de cibersegurança. A obrigação de aprovar as medidas de gestão de riscos de cibersegurança e de supervisionar a sua implementação cabe à gestão, e não apenas à equipa de TI.
A ligação ao acesso de fornecedores é direta. Se uma violação de dados tiver origem numa conta de fornecedor não controlada (sem MFA, sem registo de sessões, sem desprovisionamento após o fim do contrato) e a gestão não puder apresentar evidências de que existiam controlos e de que foram revistos, é esse o cenário para o qual o artigo 20.º foi concebido.
Incluir requisitos de acesso nos contratos e nas revisões de fornecedores
Os controlos de acesso falham quando os contratos com fornecedores não definem responsabilidades. As orientações da ENISA devem ser traduzidas em cláusulas contratuais concretas:
- Os fornecedores têm de utilizar contas nominais e aplicar MFA de nível 1 no acesso privilegiado ou remoto
- A partilha de credenciais é proibida
- Os fornecedores têm de notificar o cliente de incidentes sem demora injustificada e, o mais tardar, no prazo de 24 horas em caso de incidentes significativos
- Os subcontratantes que necessitem de acesso têm de ser divulgados e sujeitos a controlos equivalentes
- Os fornecedores têm de assegurar a conservação de logs e dar resposta a pedidos de auditoria
- As informações têm de ser devolvidas ou eliminadas no termo do contrato
As revisões de acesso devem seguir uma cadência definida: no mínimo anual para todos os fornecedores, trimestral para fornecedores com acesso privilegiado ou a sistemas de produção, e imediata após um incidente, uma alteração contratual, uma alteração de funções ou uma cessação.
Conservar as evidências de auditoria para a conformidade com a NIS2
As evidências de auditoria são o que distingue um controlo documentado de uma simples afirmação. Numa auditoria interna, numa revisão de cliente ou num pedido de supervisão, é necessário apresentar registos, e não descrições do que se pretendia fazer.
As evidências úteis incluem: registo de fornecedores, matriz de controlo de acessos, pedidos de acesso aprovados, relatórios de adesão à MFA, logs de aprovação PAM, permissões do cofre de palavras-passe, registos de rotação de tokens de API, validações de revisões de acesso, cláusulas dos contratos com fornecedores, registos de notificação de incidentes, pedidos de correção de vulnerabilidades e registos de desprovisionamento.
A aceitação de risco do acesso privilegiado de fornecedores deve ter um responsável designado. Essa aceitação, e os controlos existentes, devem ser visíveis para a gestão através de relatórios periódicos, e não enterrados numa folha de cálculo que só a equipa de TI consegue encontrar.
10 passos para a conformidade do acesso de fornecedores com a NIS2
Mapear o acesso de fornecedores, aplicar controlos, contratualizar as obrigações, monitorizar continuamente e conservar evidências. A tabela seguinte consolida todos os passos de implementação numa única referência e deve ser utilizada como lista de verificação de trabalho, não como um exercício pontual.
| Passo | O que fazer | Evidências principais |
|---|---|---|
| 1 | Mapear o acesso de fornecedores | Listar todas as ligações externas: VPN, APIs, consolas de administração SaaS, integrações CI/CD, ferramentas de suporte remoto. Atribuir um responsável interno a cada uma. |
| 2 | Criar um registo de controlo de acesso de fornecedores | Um registo por fornecedor: via de acesso, tipo de identidade, método de autenticação, nível de privilégio, cadência de revisão. |
| 3 | Aplicar contas nominais e RBAC | Substituir as contas partilhadas de fornecedores por contas individuais nominais. Limitar as permissões ao projeto específico, e não a segmentos amplos do sistema. |
| 4 | Aplicar MFA por níveis | Nível 1 (FIDO2/WebAuthn) para todo o acesso privilegiado e remoto. Nível 2 (TOTP) no mínimo para contas padrão. Abandonar progressivamente o SMS OTP. |
| 5 | Implementar PAM e armazenamento de credenciais em cofre | Acesso JIT para sessões privilegiadas, registo completo das sessões, cofre para credenciais partilhadas inevitáveis com acesso baseado em funções. |
| 6 | Rodar e analisar segredos | Definir calendários de rotação para tokens de API e credenciais de contas de serviço. Analisar repositórios à procura de segredos expostos. |
| 7 | Atualizar os contratos com fornecedores | Incluir requisitos de contas nominais, obrigações de MFA de nível 1, notificação de violações em 24 horas, direitos de auditoria, divulgação de subcontratantes e obrigações de cessação. |
| 8 | Realizar revisões de acesso | Trimestrais para fornecedores críticos, anuais para todos os outros. Imediatas após qualquer incidente, alteração contratual ou cessação. |
| 9 | Manter logs de auditoria imutáveis | Registar eventos de autenticação, escalonamentos de privilégios, atividade de sessão e alterações de configuração em todas as contas de fornecedores. |
| 10 | Automatizar o desprovisionamento | Associar a revogação de acessos aos eventos do ciclo de vida do contrato. Sem pedidos manuais: a revogação deve ser imediata e automática. |
O registo de controlo de acesso de fornecedores liga as linhas 1 a 10: um documento por relação, atualizado em cada ciclo de revisão e visível para a gestão.
Se a equipa gere palavras-passe partilhadas de fornecedores ou credenciais privilegiadas de fornecedores, um software de partilha de palavras-passe para empresas como o Passwork pode ajudar a organizar acessos, permissões e evidências de auditoria num único ambiente controlado. Constitui um componente de um programa de controlo de acessos mais amplo, e não um substituto do trabalho de governação descrito acima.
Perguntas frequentes
A NIS2 exige MFA para todo o acesso de fornecedores?
O artigo 21.º, n.º 2, alínea j), da NIS2 refere-se à MFA ou a soluções de autenticação contínua «sempre que adequado», pelo que se aplica uma abordagem baseada no risco. As orientações de 2025 da ENISA exigem MFA de nível 1 resistente a phishing (FIDO2, WebAuthn) para todo o acesso privilegiado e administrativo. Os métodos de nível 2 são aceitáveis para contas padrão sem privilégios elevados. O SMS OTP e o OTP por e-mail estão sinalizados para abandono progressivo em ambientes regulados.
O que é o Regulamento de Execução (UE) 2024/2690?
O Regulamento de Execução 2024/2690 traduz os requisitos gerais do artigo 21.º da NIS2 em mais de 150 controlos de cibersegurança específicos. No que respeita à segurança da cadeia de abastecimento, estabelece expectativas concretas em matéria de atribuição de acessos a fornecedores, gestão de contas privilegiadas e notificação de incidentes. Aplica-se diretamente a fornecedores de DNS, serviços cloud, prestadores de serviços geridos e outros tipos de entidades designadas.
A NIS2 aplica-se a subcontratantes e a fourth parties?
O artigo 21.º, n.º 2, alínea d), centra-se nas relações com fornecedores diretos e prestadores de serviços. Os contratos devem exigir a divulgação de subcontratantes e a transmissão dos requisitos de cibersegurança sempre que o acesso do fornecedor ou a continuidade do serviço dependa de um subcontratante. As orientações de 2025 da ENISA apoiam esta abordagem através das suas recomendações sobre requisitos de subcontratação nos SLAs de fornecedores.
Que evidências comprovam que os controlos de acesso de fornecedores funcionam?
As evidências úteis incluem registos de acesso de fornecedores, registos de adesão à MFA e logs de início de sessão, aprovações de sessões PAM, cláusulas contratuais que especificam requisitos de acesso, validações de revisões de acesso com data, pedidos de desprovisionamento e registos de notificação de incidentes. A combinação demonstra que os controlos existem, são aplicados e são revistos segundo um calendário definido.
Com que frequência deve o acesso de fornecedores ser revisto?
Todo o acesso de fornecedores deve ser revisto, no mínimo, anualmente. Para fornecedores com acesso privilegiado ou a sistemas de produção, as revisões trimestrais são mais adequadas. Deve desencadear-se uma revisão imediata fora do ciclo após qualquer incidente, alteração contratual, alteração de pessoal do lado do fornecedor ou cessação do contrato.
O que é um registo de controlo de acesso de fornecedores?
Um registo de controlo de acesso de fornecedores é um documento por relação que associa um fornecedor às contas específicas, vias de acesso, tipos de identidade, controlos de autenticação e registos de evidências associados a essa relação. É a unidade operacional para provar que o risco da cadeia de abastecimento foi convertido em governação de acessos aplicável ao abrigo do artigo 21.º da NIS2.
Alex Muntyan
Alex Muntyan
Alex Muntyan