Identidade descentralizada: DIDs e credenciais verificáveis entram no radar dos CISOs
Durante décadas, a identidade digital corporativa foi construída sobre uma premissa relativamente simples: a organização mantém ou delega a um provedor central a responsabilidade de identificar usuários, armazenar seus atributos e decidir em quais recursos eles podem acessar.
Diretórios corporativos, provedores de identidade (Identity Providers – IdPs), serviços de federação e plataformas de Identity and Access Management (IAM) tornaram-se, assim, componentes fundamentais da infraestrutura de Segurança da Informação.
Esse modelo continua essencial, mas uma arquitetura diferente começa a ganhar maturidade: a identidade descentralizada (Decentralized Identity).
Em vez de concentrar todas as informações necessárias para comprovar uma identidade dentro dos sistemas de uma organização ou de um provedor central, determinadas informações podem ser representadas por Credenciais Verificáveis (Verifiable Credentials – VCs), protegidas criptograficamente e apresentadas quando necessário.
A mudança pode parecer apenas tecnológica, mas suas implicações são maiores. Ela modifica a maneira como organizações estabelecem confiança digital, compartilham atributos de identidade, protegem dados pessoais e distribuem responsabilidades dentro da cadeia de autenticação e autorização.
Para CISOs e responsáveis por IAM, portanto, a pergunta deixa de ser apenas “como autenticamos esse usuário?” e passa também a envolver “como podemos confiar nos atributos digitais que esse usuário apresenta?”
O que muda com a identidade descentralizada?
No modelo tradicional de identidade digital, quando uma organização precisa confirmar informações sobre uma pessoa, normalmente recorre aos próprios registros, consulta um provedor de identidade ou depende de outra instituição que mantenha os dados considerados confiáveis.
A identidade descentralizada introduz uma abordagem diferente. Em vez de concentrar todas essas informações em bases centrais, determinados atributos podem ser representados por Credenciais Verificáveis (Verifiable Credentials – VCs), que podem ser apresentadas pelo próprio titular e verificadas criptograficamente por quem precisa confiar naquela informação.
Na prática, o modelo desloca parte da confiança do repositório que armazena os dados para a relação entre quem emite a informação, quem a apresenta e quem precisa verificá-la.
A arquitetura de Verifiable Credentials normalmente envolve três participantes principais:
Issuer (Emissor) — entidade que emite a credencial e atesta determinados atributos sobre uma pessoa, organização ou entidade.
Holder (Titular) — pessoa ou entidade que recebe a credencial e pode apresentá-la quando necessário.
Verifier (Verificador) — organização ou sistema que recebe a credencial e avalia sua autenticidade, integridade, validade e demais condições aplicáveis antes de confiar nas informações apresentadas.
Um exemplo simples ajuda a entender essa dinâmica.
Uma universidade pode emitir uma credencial digital comprovando que determinada pessoa concluiu um curso. Nesse cenário, a universidade atua como Issuer, o ex-aluno como Holder e uma empresa interessada em validar aquela formação como Verifier.
Em vez de solicitar cópias de diplomas, armazenar documentos adicionais ou depender de uma consulta manual à universidade, a empresa pode verificar criptograficamente a credencial apresentada pelo candidato e confirmar que ela foi emitida pela instituição declarada e que seu conteúdo não foi alterado.
O World Wide Web Consortium (W3C) padronizou esse modelo por meio da família Verifiable Credentials Data Model 2.0, que estabelece uma estrutura comum para emissão, apresentação e verificação de credenciais digitais.
O ponto central, portanto, não é simplesmente substituir documentos físicos por versões digitais. Trata-se de permitir a criação de declarações digitais verificáveis, cuja origem e integridade possam ser confirmadas de forma padronizada e automatizada.
Essa mudança é importante porque reduz a necessidade de confiar apenas em cópias de documentos ou em bases de dados mantidas por terceiros. A confiança passa a ser construída também sobre mecanismos criptográficos, políticas de aceitação e relações previamente estabelecidas entre emissores e verificadores.
DIDs: identificadores para uma arquitetura de confiança distribuída
Nesse ecossistema, outro elemento relevante são os Decentralized Identifiers (DIDs).
DIDs são identificadores projetados para suportar modelos de identidade digital verificável e descentralizada. Diferentemente de identificadores fortemente vinculados a um provedor central, eles podem ser utilizados de maneira menos dependente de diretórios corporativos, provedores de identidade ou outras autoridades centralizadas.
Um DID pode estar associado a um conjunto de informações necessárias para demonstrar controle sobre aquele identificador, incluindo métodos de verificação, chaves públicas e outros elementos criptográficos.
Isso introduz uma mudança importante no modelo de confiança.
Em uma arquitetura tradicional, a confiança costuma estar diretamente vinculada ao sistema responsável por manter a identidade. Se determinado diretório ou provedor reconhece um usuário, os demais sistemas passam a confiar naquela informação com base nessa relação.
Em uma arquitetura descentralizada, parte dessa confiança pode ser estabelecida por meio da combinação de identificadores, credenciais verificáveis, mecanismos criptográficos e regras que definem quais emissores são considerados confiáveis.
Em outras palavras, a identidade deixa de depender exclusivamente de uma autoridade central para passar a operar dentro de uma rede de relações de confiança verificáveis.
Isso não elimina a necessidade de confiança — e esse é um ponto essencial para os CISOs. A tecnologia pode comprovar que uma credencial foi emitida por determinada entidade e que não foi modificada, mas a organização ainda precisa decidir se aquele emissor é confiável e se aquela credencial deve ser aceita para determinado propósito.
Portanto, a identidade descentralizada não elimina a confiança do processo. Ela altera onde essa confiança é depositada, como é comprovada e quais mecanismos de governança são necessários para administrá-la.
Identidade descentralizada não é sinônimo de blockchain
Uma das associações mais comuns — e também uma das mais equivocadas — é tratar identidade descentralizada e blockchain como se fossem a mesma tecnologia.
Não são.
Blockchain ou outras formas de Distributed Ledger Technology (DLT) podem fazer parte de determinadas implementações, por exemplo, como mecanismo para publicação ou resolução de informações necessárias ao estabelecimento de confiança. Entretanto, uma blockchain não é requisito para que uma arquitetura utilize credenciais verificáveis ou determinados modelos de identidade descentralizada.
O conceito de descentralização está relacionado principalmente à possibilidade de reduzir a dependência de uma única autoridade ou repositório central para determinados processos de identidade. Em vez de exigir que todas as partes consultem continuamente uma mesma base de dados para validar informações, diferentes participantes podem estabelecer relações de confiança utilizando credenciais verificáveis, identificadores, mecanismos criptográficos e políticas de governança.
Essa distinção fica mais clara quando observamos implementações corporativas. O Microsoft Entra Verified ID, por exemplo, utiliza padrões relacionados a credenciais verificáveis e oferece suporte ao método did:web, no qual informações associadas ao identificador podem ser publicadas utilizando a própria infraestrutura Web e o controle de um domínio, sem exigir uma blockchain pública.
Portanto, a pergunta relevante para uma organização não deveria ser “precisamos de blockchain para implementar identidade descentralizada?”, mas sim:
“Qual infraestrutura e qual modelo de confiança são mais adequados para emitir, apresentar, verificar e administrar as credenciais necessárias ao nosso caso de uso?”
Essa distinção é particularmente importante para organizações que descartaram anteriormente o conceito por associá-lo automaticamente a blockchain, criptomoedas ou DLT. A discussão sobre identidade descentralizada é, antes de tudo, uma discussão sobre arquitetura de confiança digital, portabilidade de atributos e governança de identidade.
Por que esse assunto deveria entrar no radar dos CISOs?
Porque a identidade se tornou uma das principais fronteiras da cibersegurança corporativa.
O comprometimento de contas, roubo de credenciais, sequestro de sessões, abuso de privilégios e ataques contra mecanismos de autenticação demonstram que, em muitos incidentes, o atacante já não precisa necessariamente “invadir” uma organização explorando uma vulnerabilidade tradicional. Se conseguir assumir uma identidade legítima e obter os privilégios necessários, poderá operar utilizando os mesmos mecanismos disponibilizados aos usuários autorizados.
Ao mesmo tempo, o modelo tradicional de identidade levou as organizações a acumularem grandes volumes de dados pessoais, documentos e atributos utilizados para comprovar quem uma pessoa é, qual sua função, quais qualificações possui ou se atende a determinada condição.
Esses repositórios representam uma concentração significativa de risco. Quanto maior a quantidade e a sensibilidade das informações armazenadas, maior pode ser o impacto de um comprometimento.
A identidade descentralizada introduz uma possibilidade interessante: em determinados casos, verificar uma informação sem necessariamente precisar armazenar todos os dados utilizados originalmente para comprová-la.
Imagine uma organização que precise apenas confirmar que determinado profissional possui uma certificação válida. Em vez de receber e manter cópias de documentos contendo diversas informações adicionais, ela poderia receber uma credencial verificável emitida pela entidade certificadora e validar apenas os atributos necessários ao processo.
Essa abordagem pode contribuir para reduzir a coleta e retenção desnecessária de informações e favorecer princípios de minimização de dados e Privacy by Design.
Mas isso não significa que o risco desapareça.
Na realidade, ocorre uma transformação importante: a identidade descentralizada pode reduzir determinados riscos de concentração, mas simultaneamente redistribuir a superfície de ataque.
Parte do risco anteriormente concentrado em diretórios, provedores de identidade e grandes bancos de dados passa a envolver outros componentes: wallets, endpoints, chaves criptográficas, emissores de credenciais, verificadores, mecanismos de revogação ou status, serviços de resolução e frameworks de confiança.
Isso muda também a pergunta que o CISO precisa fazer.
Não basta avaliar: “Como protegemos nosso diretório de identidades?”
É necessário considerar: “Como protegemos toda a cadeia de confiança utilizada para emitir, armazenar, apresentar, verificar, revogar e aceitar uma credencial digital?”
É justamente nessa transição que está um dos aspectos mais relevantes da identidade descentralizada para a Segurança da Informação. O risco deixa de estar predominantemente concentrado em um conjunto de repositórios centrais e passa a ser distribuído entre diferentes participantes e componentes da arquitetura.
Portanto, descentralização não deve ser interpretada como sinônimo de maior segurança por definição. O benefício dependerá da arquitetura, do modelo de confiança e, principalmente, dos controles utilizados para governar todo o ciclo de vida das credenciais.
Para o CISO, a análise precisa seguir uma lógica mais ampla: Identidade → Credencial → Confiança → Risco → Controle → Evidência → Monitoramento
A tecnologia pode descentralizar determinados componentes da identidade. A responsabilidade pela gestão do risco, entretanto, continua pertencendo à organização.
O IAM tradicional não vai desaparecer — ele passará a conviver com novas formas de confiança digital
A evolução da identidade descentralizada não significa que as plataformas tradicionais de Identity and Access Management (IAM) estejam próximas de se tornar obsoletas. Pelo contrário: o cenário mais provável é de coexistência e integração entre os dois modelos.
As organizações continuarão precisando administrar funções fundamentais do ciclo de vida das identidades, como autenticação, autorização, provisionamento e desprovisionamento de contas, gestão de privilégios, segregação de funções, políticas de acesso e governança. Essas responsabilidades permanecem essenciais independentemente da forma como determinados atributos de identidade são comprovados.
É justamente nesse ponto que as Credenciais Verificáveis (Verifiable Credentials – VCs) podem acrescentar uma nova camada à arquitetura existente.
Em vez de substituir o IAM, elas podem fornecer atributos verificáveis provenientes de fontes externas confiáveis, especialmente em situações nas quais a identidade ou suas características precisam atravessar fronteiras organizacionais. Isso pode ser particularmente útil no relacionamento com clientes, fornecedores, parceiros, prestadores de serviços e outras entidades que não pertencem ao domínio de identidade interno da organização.
Uma arquitetura híbrida poderia ser representada da seguinte forma:
Usuário, cliente ou parceiro
↓
Wallet ou mecanismo de apresentação de credenciais
↓
Credencial Verificável
↓
Verificação da credencial e do emissor
↓
IAM / Identity Provider
↓
Políticas e decisões de acesso
↓
Aplicações e recursos corporativos
Nesse modelo, existe uma separação importante entre comprovar um atributo e decidir o que aquele atributo permite fazer.
Uma credencial verificável pode, por exemplo, comprovar que uma pessoa pertence a determinada empresa, possui uma certificação profissional ou atende a uma condição específica. Entretanto, essa comprovação não deveria conceder acesso automaticamente a um recurso corporativo.
A decisão de autorização continua dependendo das políticas estabelecidas pela organização e pode considerar outros fatores, como função, privilégio, contexto, risco da sessão, dispositivo utilizado, localização, nível de autenticação exigido e sensibilidade do recurso.
Em outras palavras:
Credencial verificável → comprova atributos e declarações.
IAM → utiliza identidade, atributos, contexto e políticas para governar o acesso.
Essa distinção é importante porque impede que confiança na credencial seja confundida com autorização de acesso. Uma credencial pode ser autêntica, estar válida e ter sido emitida por uma entidade reconhecida, mas isso não significa, por si só, que seu titular esteja autorizado a acessar determinado sistema ou informação.
A integração entre os dois modelos também pode ampliar as possibilidades de arquiteturas baseadas em Zero Trust, nas quais nenhuma identidade ou atributo deveria ser considerado suficiente isoladamente para estabelecer confiança permanente. Credenciais verificáveis podem fornecer sinais adicionais para a decisão, enquanto IAM, mecanismos de autenticação, políticas de acesso e controles de segurança continuam responsáveis por determinar se uma solicitação deve ser autorizada.
Por isso, a identidade descentralizada deve ser compreendida menos como uma substituição do IAM e mais como uma evolução do ecossistema de confiança digital corporativa.
O IAM continuará respondendo a uma pergunta fundamental: “O que esta identidade está autorizada a fazer?”
As credenciais verificáveis acrescentam outra: “Quais atributos sobre esta identidade consigo verificar e em quais emissores posso confiar para declará-los?”
É na combinação dessas duas dimensões — identidade e autorização de um lado, atributos verificáveis e confiança entre organizações do outro — que podem surgir alguns dos casos de uso mais relevantes da identidade descentralizada no ambiente corporativo.
Onde a identidade descentralizada pode gerar valor para as organizações
Os casos de uso mais promissores surgem justamente onde os modelos tradicionais de identidade encontram maior dificuldade: quando atributos precisam ser comprovados entre organizações que não compartilham o mesmo domínio de identidade ou infraestrutura de IAM.
Nessas situações, a organização frequentemente precisa confiar em informações produzidas por terceiros, validar documentos, consultar bases externas ou manter cópias de evidências apenas para comprovar que determinada pessoa ou empresa possui um atributo específico.
As Credenciais Verificáveis (Verifiable Credentials – VCs) podem simplificar parte desse processo ao permitir que atributos emitidos por uma fonte reconhecida sejam apresentados pelo próprio titular e verificados digitalmente pela organização que precisa utilizá-los.
O potencial de valor, portanto, não está apenas em digitalizar documentos, mas em reduzir etapas de verificação, melhorar a rastreabilidade da origem das informações e, em determinados cenários, diminuir a necessidade de armazenar dados que não são essenciais ao processo.
Onboarding de parceiros e fornecedores
O gerenciamento de terceiros é um exemplo particularmente relevante.
Grandes organizações precisam continuamente validar funcionários de fornecedores, consultores, prestadores de serviços e parceiros. Dependendo da atividade, isso pode envolver comprovação de vínculo profissional, treinamentos obrigatórios, certificações técnicas, habilitações ou outras autorizações.
Atualmente, muitos desses processos ainda dependem de documentos enviados por e-mail, formulários, consultas manuais e informações replicadas em diferentes sistemas. Além do custo operacional, isso cria problemas de atualização, rastreabilidade e proteção de dados.
Com credenciais verificáveis, determinados atributos poderiam ser emitidos pela organização responsável e posteriormente apresentados pelo profissional ao cliente. O verificador poderia então confirmar digitalmente a origem, integridade e situação da credencial antes de utilizá-la em seu processo de onboarding.
O benefício potencial é transformar parte do processo de “receber documentos e verificar informações” em “receber atributos verificáveis e avaliar sua confiança”.
Qualificações, treinamentos e certificações profissionais
Outro caso de uso natural está na comprovação de qualificações.
Universidades, entidades certificadoras, conselhos profissionais e organizações de treinamento podem emitir credenciais digitais que representem diplomas, certificações, cursos concluídos ou outras qualificações.
Uma empresa interessada em validar essas informações poderia verificar a credencial apresentada pelo profissional, reduzindo a dependência de cópias de documentos e, em determinados casos, de consultas manuais ao emissor.
Para áreas críticas, isso pode ter implicações relevantes. Imagine, por exemplo, a necessidade de comprovar que um profissional possui determinada certificação técnica antes de receber autorização para executar uma atividade sensível.
A credencial verificável não substitui a política de autorização da organização, mas pode fornecer uma evidência adicional e verificável para subsidiar aquela decisão.
Customer Identity and Access Management (CIAM)
As aplicações também podem alcançar ambientes de Customer Identity and Access Management (CIAM).
Em determinados processos, uma empresa precisa confirmar apenas um atributo do cliente — idade, qualificação, vínculo institucional ou outra condição — mas acaba recebendo documentos contendo uma quantidade muito maior de informações.
Esse modelo gera um problema conhecido de privacidade: para comprovar um único atributo, a organização coleta diversos dados que talvez não precise manter.
Dependendo da arquitetura e dos mecanismos utilizados, credenciais verificáveis podem permitir abordagens mais seletivas, nas quais a organização recebe apenas as informações necessárias para determinada finalidade.
Isso pode contribuir para estratégias de minimização de dados e Privacy by Design, além de reduzir a quantidade de informações pessoais mantidas pela organização e, consequentemente, parte da exposição associada a um eventual incidente de segurança.
É importante, entretanto, não tratar esse benefício como automático. O nível efetivo de minimização dependerá do formato da credencial, dos mecanismos de apresentação utilizados e da arquitetura implementada.
Terceiros, contratados e trabalhadores temporários
Ambientes com grande quantidade de trabalhadores temporários também apresentam um caso de uso interessante.
Um contratado pode precisar demonstrar que pertence a determinado fornecedor, concluiu um treinamento obrigatório, possui uma certificação válida ou está autorizado a executar determinada atividade.
Credenciais com escopo, validade e condições previamente estabelecidos podem ajudar a representar esses atributos durante o período necessário.
O IAM corporativo continuaria responsável por decidir quais recursos podem ser acessados. A credencial funcionaria como uma das fontes utilizadas para comprovar atributos necessários àquela decisão.
Esse ponto é fundamental:
a credencial comprova uma informação; a política corporativa decide o que fazer com ela.
Identidade entre organizações pode ser o principal campo de aplicação
Existe um elemento comum nesses exemplos: a necessidade de estabelecer confiança além das fronteiras da própria organização.
Dentro de um único ambiente corporativo, diretórios e plataformas de IAM já conseguem administrar grande parte das identidades com eficiência. O problema se torna mais complexo quando clientes, parceiros, fornecedores, universidades, entidades certificadoras e outras organizações precisam trocar e validar atributos entre si.
É justamente nesse espaço que credenciais verificáveis podem apresentar uma proposta de valor mais interessante.
Em vez de cada organização criar e manter sua própria representação completa da identidade de terceiros, determinados atributos podem ser emitidos uma vez por uma fonte reconhecida e apresentados posteriormente aos verificadores que tenham razão legítima para utilizá-los.
A arquitetura passa, portanto, de uma lógica predominantemente baseada em:
copiar → armazenar → consultar → conferir
para uma lógica potencialmente baseada em:
emitir → apresentar → verificar → decidir
Essa diferença ajuda a explicar por que identidade descentralizada pode ser especialmente relevante em ecossistemas empresariais formados por múltiplas organizações.
Credenciais verificáveis começam a chegar ao ambiente corporativo
A discussão já não está restrita a pesquisas acadêmicas, provas de conceito ou experimentos envolvendo blockchain.
Plataformas corporativas começaram a incorporar componentes desse modelo.
Um dos exemplos mais relevantes é o Microsoft Entra Verified ID, que leva conceitos de credenciais verificáveis para o ecossistema de identidade empresarial da Microsoft e utiliza padrões desenvolvidos ou mantidos por organizações como W3C, OpenID Foundation, Decentralized Identity Foundation (DIF) e Internet Engineering Task Force (IETF).
Esse movimento é importante porque sinaliza uma mudança de maturidade.
Quando tecnologias de identidade descentralizada começam a ser integradas a plataformas empresariais de IAM, a discussão deixa de ser predominantemente conceitual e passa a envolver questões práticas de arquitetura, interoperabilidade, governança, integração e gestão de riscos.
Isso não significa que credenciais verificáveis estejam prestes a substituir os mecanismos tradicionais de identidade. Significa que elas começam a se tornar mais uma capacidade disponível dentro da arquitetura corporativa de confiança digital.
Para os CISOs, essa evolução muda a pergunta.
Em vez de: “A identidade descentralizada será utilizada pelas empresas algum dia?”
A questão mais útil passa a ser: “Em quais processos estamos mantendo, replicando e verificando atributos de identidade de terceiros que poderiam ser comprovados de maneira mais eficiente por meio de credenciais verificáveis?”
E, imediatamente depois: “Quais novos riscos e dependências seriam introduzidos ao fazer isso?”
Essa combinação entre valor de negócio e análise de risco é provavelmente o melhor ponto de partida para avaliar a tecnologia.
A identidade descentralizada não precisa ser adotada porque representa uma nova tendência tecnológica. Ela passa a fazer sentido quando consegue reduzir atrito, redundância, exposição de dados ou custos de verificação sem introduzir riscos superiores aos benefícios obtidos.
O papel do NIST na evolução da identidade digital
A evolução da identidade descentralizada ocorre em paralelo a uma transformação mais ampla das referências utilizadas para estabelecer e gerenciar confiança em ambientes digitais.
Nesse contexto, o National Institute of Standards and Technology (NIST) publicou a quarta revisão de suas Digital Identity Guidelines, consolidada na série NIST SP 800-63-4. As diretrizes oferecem uma referência técnica para diferentes etapas do ciclo de vida da identidade digital, desde a comprovação inicial da identidade até autenticação, gerenciamento de autenticadores e federação entre diferentes domínios.
A série é estruturada em documentos complementares que tratam de componentes específicos desse processo:
- NIST SP 800-63A-4 — Identity Proofing and Enrollment: aborda comprovação de identidade e enrollment;
- NIST SP 800-63B-4 — Authentication and Authenticator Management: trata dos processos de autenticação e gerenciamento dos autenticadores;
- NIST SP 800-63C-4 — Federation and Assertions: estabelece diretrizes relacionadas à federação de identidade e assertions.
Essa estrutura é relevante porque reforça uma ideia fundamental: identidade digital não deve ser analisada apenas pelo mecanismo utilizado para autenticar um usuário. O nível de confiança obtido depende de uma cadeia que começa na comprovação da identidade, passa pela emissão e gerenciamento dos autenticadores e alcança a forma como informações sobre aquela identidade são utilizadas ou compartilhadas entre sistemas.
É importante, entretanto, separar claramente referência técnica de requisito de adoção.
A NIST SP 800-63-4 não determina que organizações implementem identidade descentralizada, DIDs ou Credenciais Verificáveis. Portanto, não seria tecnicamente correto utilizar a publicação como evidência de que o NIST exige ou recomenda, de forma geral, a adoção dessa arquitetura.
Sua relevância para esse debate é outra: muitos dos problemas tratados pelas Digital Identity Guidelines — identity proofing, autenticação, ciclo de vida, federação e estabelecimento de níveis adequados de confiança — continuam existindo quando uma organização adota arquiteturas baseadas em credenciais verificáveis.
A tecnologia pode mudar. A necessidade de demonstrar por que uma identidade ou atributo deve ser considerado confiável permanece.
A descentralização muda o risco — não o elimina
Esse princípio é particularmente importante sob a perspectiva do CISO.
Identidade descentralizada não deve ser tratada como uma solução inerentemente mais segura apenas por reduzir a dependência de determinados componentes centralizados.
Ela pode diminuir alguns riscos, especialmente aqueles associados à concentração desnecessária de informações, mas simultaneamente redistribui a superfície de ataque e cria novas dependências de segurança.
O resultado é uma mudança no modelo de ameaças.
Em uma arquitetura tradicional, grande parte da atenção está concentrada na proteção de diretórios, Identity Providers, bancos de dados de identidade, mecanismos de autenticação e sistemas de IAM.
Em uma arquitetura descentralizada, essa análise precisa ser ampliada para incluir wallets, endpoints, chaves criptográficas, emissores, verificadores, mecanismos de status ou revogação, serviços de resolução e os próprios frameworks de confiança utilizados pelo ecossistema.
Gerenciamento de chaves torna-se uma função crítica
A criptografia está no centro das credenciais verificáveis. Consequentemente, o gerenciamento adequado das chaves utilizadas pelos diferentes participantes passa a ser um dos elementos críticos da arquitetura.
Comprometimento, perda, utilização indevida ou gerenciamento inadequado desse material criptográfico pode afetar a capacidade de verificar credenciais ou estabelecer confiança sobre sua origem.
O problema não termina na proteção da chave. A organização precisa considerar todo o seu ciclo de vida: geração, armazenamento, utilização, rotação, recuperação, revogação e descarte, além dos mecanismos utilizados para responder a um eventual comprometimento.
Ou seja, quanto maior a dependência da criptografia para estabelecer confiança, maior precisa ser a maturidade dos processos de Key Management.
Wallets e endpoints entram na superfície de ataque
Quando credenciais são armazenadas ou apresentadas por meio de wallets, essas aplicações e os dispositivos nos quais operam passam a fazer parte da cadeia de confiança.
Isso cria uma questão importante: uma credencial criptograficamente protegida não está necessariamente protegida contra o comprometimento do ambiente no qual é utilizada.
Malware, roubo de sessão, comprometimento do endpoint, engenharia social ou falhas na própria wallet podem permitir utilização indevida de credenciais legítimas.
A segurança precisa, portanto, considerar não apenas a credencial, mas também quem consegue utilizá-la, em qual dispositivo, sob quais condições e com quais mecanismos de proteção.
Revogação e status precisam funcionar durante todo o ciclo de vida
Uma credencial autêntica não permanece necessariamente confiável para sempre.
Um funcionário pode deixar uma organização. Uma certificação pode expirar. Uma autorização profissional pode ser suspensa. Uma credencial pode ter sido emitida incorretamente ou precisar ser revogada após um incidente.
Por isso, não basta verificar se a assinatura criptográfica é válida.
O Verifier precisa ser capaz de determinar se aquela credencial continua aceitável no momento em que está sendo utilizada.
A arquitetura deve prever mecanismos para gerenciamento de expiração, suspensão, revogação ou outras mudanças de status sem comprometer desnecessariamente a privacidade do titular.
O maior desafio pode estar na confiança no emissor
Esse talvez seja o ponto mais importante sob a perspectiva de governança.
Imagine uma credencial cuja assinatura criptográfica seja perfeitamente válida. O conteúdo não foi modificado e é possível demonstrar tecnicamente quem a emitiu.
Ainda resta uma pergunta fundamental:
por que a organização deveria confiar naquele emissor para declarar aquele atributo?
A criptografia pode demonstrar a origem e a integridade de uma declaração, mas não determina automaticamente se quem fez a declaração possui autoridade, competência ou legitimidade para fazê-la.
Uma organização precisa estabelecer políticas que determinem quais emissores são aceitos, quais tipos de credenciais podem emitir e para quais decisões essas credenciais poderão ser utilizadas.
A questão deixa de ser apenas tecnológica e passa a ser de governança da confiança.
Auditoria e rastreabilidade tornam-se mais distribuídas
Arquiteturas descentralizadas também podem aumentar a complexidade da auditoria.
Em ambientes tradicionais, uma parte significativa dos eventos relacionados à identidade pode estar concentrada no Identity Provider, IAM, diretórios e aplicações corporativas. Em um ecossistema distribuído, diferentes componentes podem participar de uma mesma transação de confiança.
A organização precisa estabelecer quais eventos devem ser registrados, quais evidências precisam ser preservadas e como decisões baseadas em credenciais poderão ser reconstruídas posteriormente.
Para ambientes corporativos, isso significa pensar desde o projeto na integração com logging, SIEM, SOC, processos de auditoria e resposta a incidentes.
Não basta saber que uma credencial foi aceita. Dependendo do risco, pode ser necessário demonstrar qual credencial foi avaliada, qual política foi aplicada, qual decisão foi tomada e quais evidências sustentaram essa decisão, observados os requisitos de privacidade e minimização aplicáveis.
Padrões não garantem interoperabilidade automática
O desenvolvimento de padrões pelo W3C e outras organizações é fundamental para ampliar a interoperabilidade, mas utilizar padrões comuns não significa que todas as implementações funcionarão automaticamente entre si.
Diferenças entre formatos, métodos DID, wallets, protocolos de apresentação, mecanismos criptográficos, modelos de confiança e funcionalidades proprietárias podem gerar dificuldades de integração.
Por isso, interoperabilidade precisa ser testada e demonstrada, e não simplesmente presumida porque diferentes fornecedores declaram aderência aos mesmos padrões.
Descentralização também pode criar dependência de fornecedores
Existe ainda uma aparente contradição que merece atenção.
Uma arquitetura pode utilizar padrões de identidade descentralizada e, mesmo assim, tornar a organização altamente dependente de uma plataforma comercial específica.
Componentes proprietários para emissão, gerenciamento, armazenamento, verificação ou integração podem criar vendor lock-in, dificultando posteriormente a migração para outro fornecedor.
Antes da adoção, portanto, a organização deve avaliar não apenas se a solução utiliza padrões abertos, mas também quais componentes permanecem proprietários, como credenciais e configurações podem ser migradas e o que aconteceria caso o fornecedor deixasse de prestar o serviço.
O modelo de risco precisa acompanhar o modelo de identidade
A principal conclusão para o CISO é que descentralizar determinados componentes da identidade não descentraliza a responsabilidade pela segurança.
O risco apenas assume outra configuração.
Em vez de concentrar a análise predominantemente em diretórios, bancos de dados e Identity Providers, torna-se necessário avaliar toda uma cadeia:
Emissor → Credencial → Chaves → Wallet → Titular → Verificador → Política de confiança → IAM → Decisão de acesso → Evidência → Monitoramento
Uma fragilidade em qualquer ponto dessa cadeia pode comprometer o resultado esperado.
Por isso, a adoção de identidade descentralizada não deveria começar pela escolha de uma tecnologia. Deveria começar pela definição do modelo de confiança, dos casos de uso e das ameaças que precisam ser controladas.
A pergunta relevante não é simplesmente:
“A arquitetura é descentralizada?”
Mas:
“Conseguimos demonstrar, de ponta a ponta, por que devemos confiar na identidade, na credencial, no emissor, no dispositivo que a apresenta e na decisão tomada a partir dela?”
É essa capacidade — e não apenas a utilização de criptografia ou padrões descentralizados — que determinará o nível real de segurança da arquitetura.
Autenticidade criptográfica não significa confiança
Esse talvez seja um dos princípios mais importantes para compreender corretamente uma arquitetura baseada em credenciais verificáveis: comprovar criptograficamente a origem de uma informação não significa, por si só, que essa informação deva ser considerada confiável pela organização.
Imagine uma credencial digital corretamente assinada por uma entidade desconhecida. A assinatura pode ser perfeitamente válida e sua verificação criptográfica pode demonstrar que a credencial foi assinada utilizando determinada chave e que seu conteúdo não foi alterado após a assinatura.
Tecnicamente, portanto, existem evidências de autenticidade e integridade.
Mas ainda permanece uma questão essencial:
Por que a organização deveria confiar naquele emissor para declarar aquele atributo?
Uma universidade reconhecida pode ter legitimidade para emitir uma credencial comprovando uma formação acadêmica. Uma entidade certificadora pode ser reconhecida para declarar determinada certificação profissional. Uma empresa pode atestar o vínculo de seus próprios funcionários.
Mas uma assinatura criptográfica, isoladamente, não demonstra que o emissor possui autoridade, competência ou legitimidade para fazer determinada declaração.
É justamente nesse ponto que tecnologia e governança se encontram.
A organização precisa estabelecer um modelo de confiança que determine quais emissores serão reconhecidos, quais tipos de credenciais cada um poderá emitir, para quais finalidades essas credenciais poderão ser utilizadas e quais condições deverão ser atendidas antes que uma informação seja aceita em um processo corporativo.
Em termos simples:
Autenticidade criptográfica responde: “Quem assinou esta declaração e ela foi alterada?”
Governança responde: “Devemos confiar nesse emissor para fazer essa declaração e utilizá-la nesta decisão?”
Por isso:
Validade criptográfica ≠ confiança organizacional.
A criptografia fornece mecanismos para demonstrar origem e integridade. A confiança, entretanto, depende também de políticas, relações institucionais, critérios de aceitação, processos de governança e avaliação de risco.
Essa distinção é especialmente importante quando uma credencial influencia decisões de acesso. Uma credencial pode ser autêntica, estar dentro de sua validade e ter sido emitida corretamente e, ainda assim, não ser suficiente para autorizar o acesso a determinado recurso.
Em outras palavras, a tecnologia pode comprovar uma declaração. A organização continua responsável por decidir quanto deve confiar nela e o que pode ser feito a partir dessa confiança.
Privacidade pode ser um dos maiores benefícios
A possibilidade de reduzir a exposição desnecessária de informações talvez seja um dos aspectos mais interessantes das credenciais verificáveis.
Muitos processos atuais foram construídos segundo uma lógica documental: para comprovar apenas uma informação, o indivíduo frequentemente precisa apresentar um documento contendo diversos outros dados.
Considere um processo no qual seja necessário apenas confirmar que uma pessoa possui determinada qualificação profissional. Dependendo do procedimento adotado, a organização pode receber cópias de documentos contendo nome completo, número de identificação, data de nascimento, fotografia, endereço ou outras informações que não são necessárias para aquela finalidade específica.
O resultado é um problema recorrente de privacidade: para comprovar um atributo, coleta-se um conjunto muito maior de dados.
Credenciais verificáveis podem ajudar a modificar essa lógica.
Dependendo da arquitetura, do formato da credencial e dos mecanismos criptográficos utilizados, pode ser possível apresentar apenas os atributos necessários para determinada transação, evitando a exposição de outras informações contidas na credencial ou nos documentos utilizados originalmente para sua emissão.
Em implementações que suportem mecanismos adequados de divulgação seletiva (selective disclosure), essa possibilidade se torna ainda mais relevante: o titular pode demonstrar determinados atributos sem necessariamente revelar todo o conjunto de informações associado à credencial.
A lógica deixa de ser: “Envie o documento para que possamos encontrar a informação necessária.”
e passa a se aproximar de: “Apresente apenas a informação necessária e uma forma confiável de verificá-la.”
Sob a perspectiva de privacidade, essa mudança pode contribuir para princípios de minimização de dados e Privacy by Design, reduzindo a coleta e retenção de informações pessoais que não são necessárias para determinada finalidade.
Do ponto de vista da gestão de riscos, existe também uma relação importante: Menos dados coletados → menos dados armazenados → menor quantidade de informações potencialmente expostas em um incidente.
Esse benefício, entretanto, não é automático.
Uma implementação inadequada pode continuar coletando atributos excessivos, registrar apresentações desnecessariamente, permitir correlação entre diferentes transações ou manter informações por períodos superiores aos necessários. A utilização de credenciais verificáveis, por si só, não garante privacidade.
Por isso, o desenho da arquitetura deve considerar desde o início quais atributos são realmente necessários, quais informações serão apresentadas, o que será registrado pelo verificador, por quanto tempo esses registros serão mantidos e quais mecanismos poderão reduzir a correlação desnecessária entre diferentes interações.
No contexto brasileiro, essa abordagem também apresenta uma correlação técnica relevante com o princípio da necessidade previsto na LGPD, segundo o qual o tratamento deve ser limitado ao mínimo necessário para a realização de suas finalidades. Isso não significa que a LGPD exija credenciais verificáveis; significa que uma arquitetura adequadamente projetada pode contribuir tecnicamente para implementar estratégias de minimização de dados.
Assim, o potencial de privacidade da identidade descentralizada não está simplesmente em distribuir informações entre diferentes sistemas. Está na possibilidade de mudar uma prática historicamente comum:
de coletar documentos para comprovar atributos para verificar atributos sem necessariamente coletar todos os dados existentes nos documentos.
Para organizações que processam grandes volumes de informações pessoais, essa diferença pode representar não apenas maior privacidade, mas também redução da superfície de exposição, do impacto potencial de incidentes e da quantidade de dados que precisam ser protegidos durante todo o seu ciclo de vida.
O que o CISO deveria perguntar antes de adotar a tecnologia?
Antes de implementar identidade descentralizada, o debate não deveria começar pela escolha de uma wallet, blockchain ou plataforma tecnológica.
Deveria começar pelo modelo de confiança e pelo risco.
Algumas perguntas são fundamentais:
- Caso de negócio: qual problema concreto de identidade estamos tentando resolver?
- Modelo de confiança: quais organizações serão reconhecidas como emissores confiáveis?
- Arquitetura: como credenciais, DIDs, verificadores e wallets serão integrados ao IAM existente?
- Lifecycle Management: como emissão, expiração, suspensão, renovação e revogação serão administradas?
- Segurança: como chaves criptográficas e dispositivos serão protegidos?
- Privacidade: quais informações realmente precisam ser apresentadas e armazenadas?
- Governança: quem será responsável por definir quais emissores e credenciais são aceitos?
- Auditoria: quais evidências precisarão ser preservadas?
- Monitoramento: como eventos relacionados a credenciais serão incorporados ao SOC, SIEM e processos de resposta a incidentes?
- Continuidade: o que acontecerá se um emissor, wallet, serviço de resolução ou componente crítico ficar indisponível?
Essa análise pode ser resumida pela cadeia: Caso de uso → Modelo de confiança → Risco → Controle → Implementação → Evidência → Monitoramento
Essa abordagem impede que a organização comece pela tecnologia antes de entender o problema que pretende resolver.
O verdadeiro desafio não é descentralizar a identidade, mas descentralizar a confiança
A identidade descentralizada representa uma mudança importante na arquitetura de identidade digital.
No modelo tradicional, uma das perguntas predominantes é: “Meu sistema conhece e autenticou esse usuário?”
Em uma arquitetura baseada em credenciais verificáveis, surge uma segunda pergunta: “Posso confiar no atributo apresentado, no emissor que o declarou e no mecanismo utilizado para demonstrar sua autenticidade?”
Essa mudança parece sutil, mas é profunda.
Ela desloca parte do problema da identidade de um modelo predominantemente baseado em cadastro e autenticação para outro que também precisa administrar proveniência, verificabilidade e relações de confiança entre diferentes participantes.
É justamente por isso que o tema deve entrar no radar dos CISOs. A questão estratégica não é decidir se o IAM tradicional será substituído por identidade descentralizada. Tudo indica que, no curto e médio prazo, essas arquiteturas deverão coexistir.
A pergunta mais relevante é outra: quais partes do processo de confiança digital podem ser descentralizadas de maneira segura, reduzindo exposição de dados e atrito operacional sem comprometer governança, rastreabilidade, revogação e controle de acesso?
As organizações capazes de responder adequadamente a essa pergunta poderão encontrar casos de uso relevantes para credenciais verificáveis.
Mas existe uma conclusão ainda mais importante: criptografia pode provar a origem de uma credencial; não pode decidir em quem uma organização deve confiar.
Essa continuará sendo uma responsabilidade de governança.
Referências
TechTarget — CISO’s guide to decentralized identity: What works and what doesn’t
Publicado em 18 de agosto de 2026.
Acessar artigo da TechTarget
W3C — Verifiable Credentials 2.0
A família de especificações tornou-se W3C Recommendation em 15 de maio de 2025.
Verifiable Credentials 2.0 — W3C
W3C — Decentralized Identifiers (DIDs)
O DID Core v1.0 é W3C Recommendation; a versão 1.1 encontra-se em evolução no processo de padronização.
Decentralized Identifiers — W3C
NIST — SP 800-63-4 Digital Identity Guidelines
Publicada em 2025 e sucessora da SP 800-63-3.
NIST SP 800-63-4
Microsoft — Entra Verified ID
Documentação da implementação de identidade descentralizada e credenciais verificáveis da Microsoft.
Microsoft Entra Verified ID
Clique e fale com representante oficial Netwrix Endpoint Protector
Veja também:
- AWS Kiro: quando uma página maliciosa transforma Prompt Injection em execução de código
- Pentest em Sistemas de IA
- Microsoft SharePoint sob ataque: CVE-2026-50522 permite execução remota de código e exige ação imediata
- Amatera Stealer usa blockchain para ocultar servidores C2
- Ransomware em 2026: número de vítimas bate recorde
- Top 10 Malware usados por Hackers
- O resgate não é o custo do ransomware
- Microsoft Defender pode ser transformado em arma contra EDR e antivírus
- Shadow AI: 47% do uso corporativo de IA ocorre em contas pessoais
- Cibersegurança: 95% das equipes enfrentam lacunas de habilidades
- Credenciais móveis avançam como pilar da segurança bancária
- Ransomware mira backups em 96% dos ataques
Be the first to comment