EUDI Wallet: Who Must Accept it by 2027?

A obrigação de aceitação da EUDI Wallet nomeia onze sectores no artigo 5.º-F, n.º 2, do Regulamento eIDAS na versão alterada: transportes, [...]

Mas estar num desses sectores não basta por si. Duas condições têm de verificar-se ao mesmo tempo antes de a obrigação de aceitação da EUDI Wallet o alcançar: já estar sujeito a uma obrigação legal ou contratual de usar autenticação forte do utilizador para identificação em linha, e não ser uma micro ou pequena empresa. É por isso que duas empresas do mesmo sector podem chegar a conclusões opostas.

Ambas as datas vêm de um único acontecimento. A 28 de novembro de 2024 a Comissão Europeia adoptou os primeiros cinco actos de execução ao abrigo do Regulamento (UE) 2024/1183, e entraram em vigor a 24 de dezembro de 2024 após publicação no Jornal Oficial. O regulamento conta os seus prazos a partir desse momento.

24 dez 2024

Entram em vigor os primeiros cinco actos de execução

24 dez 2026

Os Estados-Membros têm de disponibilizar pelo menos uma carteira. Começa a aceitação pelo sector público

24 dez 2027

Obrigação de aceitação pelo sector privado, ao abrigo do artigo 5.º-F, n.º 2

Depois disso

A Comissão avalia procura, disponibilidade e usabilidade no prazo de 24 meses após a implantação

Dezembro de 2026 é quando as carteiras existem. Não é quando a sua organização tem de as aceitar.

Que sectores são nomeados na obrigação de aceitação da EUDI Wallet?

Onze. A lista de sectores é a parte fácil da análise e é onde a maioria da cobertura para. Onde a obrigação incide na prática difere por sector: abertura de conta e autorização de pagamento na banca, onboarding e identificação de investidores nos serviços financeiros, bilhética nos transportes, contas de cliente e mudança de fornecedor na energia, acesso a prestações na segurança social, portais de doente e serviços de prescrição na saúde, contas de cliente na água potável, entrega registada nos serviços postais, acesso administrativo na infraestrutura digital, inscrição e emissão de credenciais na educação, e registo de SIM e recuperação de conta nas telecomunicações.

Esse mapeamento é a nossa leitura de onde o requisito incide, não texto do regulamento. O regulamento nomeia os sectores e o gatilho, e deixa o mapeamento para os seus próprios processos.

Quais são as duas condições que têm de verificar-se as duas?

Condição um

Já usa autenticação forte porque é obrigado a isso

A obrigação recai sobre partes confiantes sujeitas a uma obrigação legal ou contratual de usar autenticação forte do utilizador para identificação em linha. Não sobre todos os que têm um ecrã de login. A palavra contratual está a fazer trabalho a sério: uma obrigação que aceitou num contrato com um cliente, um esquema ou um regulador pode colocá-lo em âmbito onde nenhuma lei o nomeia directamente.

Condição dois

Não é uma micro ou pequena empresa

Micro e pequenas empresas estão excluídas. Segundo a definição europeia, uma pequena empresa emprega menos de 50 pessoas e tem um volume de negócios anual ou balanço total que não excede 10 milhões de euros. Tanto o número de efectivos como um dos limiares financeiros têm de estar satisfeitos para ficar abaixo do tecto.

E a condição que a maioria ignora: a aceitação é exigida a pedido voluntário do utilizador. A carteira não está a ser imposta aos cidadãos, e não lhe estão a pedir para substituir a sua autenticação actual. Essa distinção altera consideravelmente a forma do projecto. É uma rota adicional para o seu fluxo de identidade, não uma migração.

Estar isento significa não ser afectado?

Não, e esta é a parte mais útil do artigo para a maioria dos leitores, porque a maioria das organizações que o lêem não está em âmbito.

Os seus clientes estão em âmbito. Se vende software a bancos, telecomunicações ou prestadores de saúde, o seu produto passa a fazer parte da posição de conformidade deles. A mesma dinâmica já se aplica ao abrigo do DORA, que abordámos em o que as equipas de QA na banca têm de provar aos supervisores. Conte que o suporte à carteira apareça em concursos e em negociações de renovação bem antes de dezembro de 2027

Os seus utilizadores vão ter uma. Quando os cidadãos tiverem carteira e a usarem no banco, vão esperá-la noutros sítios. Não a aceitar passa a ser um custo de atrito e não uma falha de conformidade, que é um problema diferente com a mesma solução.

A aceitação voluntária é explicitamente encorajada. O regulamento prevê códigos de conduta para encorajar prestadores fora do âmbito obrigatório a aceitar carteiras, e prevê que a Comissão avalie procura e usabilidade no prazo de 24 meses após a implantação.

O que vale dizer com clareza: a isenção é razão para planear no seu próprio calendário, não razão para não planear nada.

Não tem a certeza de que lado da linha está a sua organização?

Fale com a nossa equipa

O que se aplica a organismos públicos e a plataformas em linha de muito grande dimensão?

Três obrigações, três datas

Sector público

Onde a identificação electrónica é exigida para acesso a um serviço público em linha, as carteiras também têm de ser aceites. A partir de 24 de dezembro de 2026

›

Plataformas em linha de muito grande dimensão

As plataformas designadas ao abrigo do Regulamento (UE) 2022/2065 estão cobertas pela obrigação de aceitação do artigo 5.º-F. A partir de 24 de dezembro de 2027

›

Partes confiantes privadas

Os onze sectores nomeados, onde as duas condições se verificam, a pedido voluntário do utilizador. A partir de 24 de dezembro de 2027

A data do sector público importa mesmo a empresas privadas. A partir de dezembro de 2026 haverá serviços em produção a aceitar carteiras em todos os Estados-Membros, que é o primeiro momento em que se pode testar contra algo real e não contra uma implementação de referência.

O que exige efectivamente aceitar a carteira?

Quatro coisas, e apenas uma delas é o que a maioria das equipas imagina.

Registar-se como parte confiante. Um passo formal junto da autoridade nacional, não uma alteração de configuração, e envolve declarar o que pretende pedir. O registo é pré-requisito para pedir atributos, por isso pertence ao início de um plano de projecto e não ao fim.

Pedir apenas o que precisa. O quadro está construído em torno da divulgação selectiva, o que permite perguntar se alguém tem mais de dezoito anos em vez de receber uma data de nascimento. Pedir o conjunto completo de identidade porque está tecnicamente disponível contraria tanto o desenho do sistema como a minimização de dados.

Validar o que chega. Uma atestação apresentada tem de ser verificada contra a lista de confiança aplicável, que é um modelo de verificação diferente de verificar um documento ou um certificado de eID nacional, ou de ler um Cartão de Cidadão directamente.

Manter um caminho para todos os outros. O uso da carteira é voluntário para os cidadãos, por isso a sua rota de identificação existente tem de continuar a funcionar em paralelo no futuro previsível.

O último ponto é o que altera orçamentos. Isto é uma adição à sua stack de identidade, não uma substituição, o que significa manter dois caminhos e reconciliar o que cada um produz. O lado técnico está coberto no nosso guia de integração de relying party, a decisão de formato de credencial em SD-JWT VC ou ISO mdoc, e o panorama mais amplo de obrigações no nosso Guia de implementação do eIDAS 2.0.

O que deve ficar resolvido antes do fim de 2026?

Quatro perguntas, por esta ordem. Nenhuma é uma tarefa de desenvolvimento, e todas bloqueiam uma. Está em âmbito, estabelecido por escrito por quem tem a área jurídica. Quais dos seus fluxos são afectados, lembrando que o onboarding raramente é o único e que recuperação de conta, alterações contratuais, identificação presencial e verificação de back-office são todos fluxos de identificação. O que vai efectivamente pedir, decidido por fluxo antes de alguém desenhar um ecrã. E quem faz o registo, e quando, tratando o registo de parte confiante como uma dependência de prazo junto de uma entidade externa.

Se está em âmbito e nenhuma das quatro tem responsável, isso é o achado, e dezembro de 2027 está mais perto do que parece.

Leitura relacionada

Guia de integração de relying party da EUDI Wallet Depois de saber que está em âmbito, este é o lado de engenharia: registo, pedidos de atributos e validação contra a lista de confiança.

SD-JWT VC ou ISO mdoc: qual construir primeiro? O quadro exige os dois formatos. Qual sequenciar primeiro depende do que verifica e onde.

Guia de implementação do eIDAS 2.0 O conjunto mais amplo de obrigações que chegam antes de dezembro de 2026.

O que o LisbonID 2026 nos disse sobre identidade digital na Europa Onde a ambição política e a realidade operacional ainda divergem, a partir das intervenções da conferência.

eID Box Middleware de identidade para organizações que têm de aceitar credenciais de mais do que uma fonte.

Perguntas frequentes

Âmbito da obrigação de aceitação da EUDI Wallet

Que sectores têm de aceitar a EUDI Wallet?

O artigo 5.º-F, n.º 2, do Regulamento eIDAS na versão alterada nomeia transportes, energia, banca, serviços financeiros, segurança social, saúde, água potável, serviços postais, infraestrutura digital, educação e telecomunicações. Os prestadores de plataformas em linha de muito grande dimensão ao abrigo do Regulamento dos Serviços Digitais também estão cobertos. A obrigação aplica-se a partir de 24 de dezembro de 2027.

A minha empresa está isenta da obrigação da EUDI Wallet?

Está fora do âmbito obrigatório se não pertencer a um dos onze sectores nomeados, se não estiver sujeita a uma obrigação legal ou contratual de usar autenticação forte do utilizador para identificação em linha, ou se for uma micro ou pequena empresa. Uma pequena empresa emprega menos de 50 pessoas com volume de negócios ou balanço total que não excede 10 milhões de euros.

As duas datas

Porque é que se citam tanto dezembro de 2026 como dezembro de 2027?

Porque ambos são reais e medem coisas diferentes. Os primeiros cinco actos de execução entraram em vigor a 24 de dezembro de 2024. Os Estados-Membros têm de disponibilizar uma carteira 24 meses depois, a 24 de dezembro de 2026. A obrigação de aceitação pelo sector privado segue 12 meses mais tarde, a 24 de dezembro de 2027.

Aceitar a carteira significa substituir o nosso login actual?

Não. A aceitação é exigida a pedido voluntário do utilizador, e o uso da carteira é voluntário para os cidadãos. As suas rotas de identificação existentes têm de continuar a funcionar em paralelo com a carteira, o que faz disto uma adição à sua stack de identidade e não uma migração.

O que significa na prática

Precisamos de nos registar antes de aceitar carteiras?

Sim. As partes confiantes têm de se registar junto da autoridade nacional competente e declarar a utilização prevista antes de pedir atributos a uma carteira. Como o registo depende de uma entidade externa, é um item de prazo e pertence ao início de um plano de projecto.

O que acontece se estivermos isentos mas os nossos clientes não?

A obrigação deles passa a ser o seu requisito comercial. Se fornece software ou serviços a organizações nos onze sectores nomeados, o suporte à carteira tem probabilidade de aparecer nos processos de compra e de renovação deles antes de dezembro de 2027, independentemente de o regulamento o nomear.

Equipa Caixa Mágica

A Caixa Mágica Software é uma empresa portuguesa de software com mais de 20 anos de experiência a entregar software à medida, soluções de IA e equipas de desenvolvimento nearshore para organizações europeias. Trabalhamos em middleware de identidade electrónica nacional há mais de uma década.

eID Box · Caixa Mágica Software

Descubra quais dos seus fluxos estão em âmbito

Envie-nos o seu sector e os fluxos onde verifica identidade hoje. Dizemos-lhe quais estão provavelmente em âmbito, como é o caminho de registo, e onde a obrigação de aceitação vai além do onboarding.

Conhecer o eID Box Fale connosco