--- url: 'https://www.corbado.com/pt/blog/pci-dss-4-0-autenticacao-passkeys' title: 'Autenticação no PCI DSS 4.0: Passkeys' description: 'Saiba como a autenticação com passkeys atende aos requisitos de MFA do PCI DSS 4.0, aumenta a segurança e simplifica a conformidade para comerciantes que lidam com dados de titulares de cartão.' lang: 'pt' author: 'Vincent Delitz' date: '2025-07-15T13:24:23.651Z' lastModified: '2026-03-26T07:02:52.171Z' keywords: 'pci dss, pci, autenticação pci, pci ssc' category: 'Passkeys Strategy' --- # Autenticação no PCI DSS 4.0: Passkeys ## 1. Introdução O cenário digital está em constante evolução e, com ele, a sofisticação e a frequência das ameaças cibernéticas continuam a aumentar. Os dados de cartões de [pagamento](https://www.corbado.com/passkeys-for-payment) continuam a ser um alvo principal para agentes mal-intencionados, tornando os padrões de segurança robustos essenciais para qualquer organização que os manuseie. O Padrão de Segurança de Dados da Indústria de Cartões de [Pagamento](https://www.corbado.com/passkeys-for-payment) (PCI DSS) serve há muito tempo como referência para a proteção de dados de titulares de cartão. A sua mais recente iteração, o [PCI DSS](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) 4.0, representa um [passo significativo em frente](https://listings.pcisecuritystandards.org/documents/PCI-DSS-v3-2-1-to-v4-0-Summary-of-Changes-r1.pdf), abordando diretamente as ameaças modernas através de, entre outras melhorias, requisitos de [autenticação](https://www.corbado.com/pt/blog/passkeys-revolut) substancialmente reforçados. À medida que as organizações lidam com estas novas exigências, as tecnologias emergentes oferecem soluções promissoras. As passkeys, construídas com base nos padrões da [FIDO](https://www.corbado.com/pt/glossary/attestation) (Fast Identity Online) Alliance e no protocolo WebAuthn, estão na vanguarda desta nova onda de [autenticação](https://www.corbado.com/pt/blog/passkeys-revolut). Elas oferecem uma abordagem sem senha e [resistente a phishing](https://www.corbado.com/pt/blog/como-eliminar-senhas-por-completo), e melhoram a forma como o acesso a dados sensíveis é protegido. **Este artigo analisa as mudanças críticas trazidas pelo PCI DSS 4.0, especialmente no que diz respeito à autenticação segura**, explora as capacidades da [autenticação](https://www.corbado.com/pt/blog/passkeys-revolut) com passkeys e fornece um roteiro para alavancar esta tecnologia para alcançar e manter a conformidade. Esta exploração leva a duas questões importantes para as organizações que navegam nesta nova fronteira: 1. **Autenticação**: _Com o PCI DSS 4.0 a elevar o padrão de autenticação, como podem as organizações cumprir eficazmente estes novos e rigorosos requisitos sem sobrecarregar os utilizadores ou as equipas de segurança?_ 2. **Passkeys e Conformidade com PCI**: _Podem tecnologias emergentes como as passkeys satisfazer os controlos de autenticação do PCI DSS 4.0, melhorar a segurança e a eficiência operacional?_ Este artigo [visa](https://www.corbado.com/blog/visa-passkeys) fornecer respostas, guiando os profissionais técnicos em direção a um futuro mais seguro e em conformidade. ## 2. Compreender o PCI DSS e as Mudanças para a Versão 4.0 Para apreciar o papel das passkeys no atual cenário de conformidade, é crucial compreender a estrutura do [PCI DSS](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) e a evolução significativa marcada pela versão 4.0. ### 2.1 O que é o Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI DSS)? O [Padrão de Segurança de Dados do PCI](https://www.pcisecuritystandards.org/standards/) é um padrão global de segurança da informação concebido para proteger dados de [pagamento](https://www.corbado.com/passkeys-for-payment). Aplica-se a todas as entidades que armazenam, processam ou transmitem dados de titulares de cartão, abrangendo merchants, processadores, acquirers, issuers e prestadores de serviços. O padrão foi [desenvolvido pelas principais marcas de cartões de pagamento](https://en.wikipedia.org/wiki/Payment_Card_Industry_Security_Standards_Council) (American Express, Discover [Financial Services](https://www.corbado.com/passkeys-for-banking), JCB International, [MasterCard](https://www.corbado.com/blog/mastercard-passkeys) e [Visa](https://www.corbado.com/blog/visa-passkeys)), que formaram o Conselho de Padrões de Segurança do [PCI](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) (PCI SSC) a 7 de setembro de 2006, para gerir a sua evolução contínua. O [PCI DSS](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) consiste num conjunto abrangente de [requisitos técnicos e operacionais](https://www.pcisecuritystandards.org/standards/), formando uma base para proteger os dados de pagamento ao longo do seu ciclo de vida. ### 2.2 O Conselho de Padrões de Segurança do PCI (PCI SSC) e a sua Missão O [PCI SSC](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) opera como um [fórum global](https://www.pcisecuritystandards.org/), reunindo [stakeholders](https://www.corbado.com/blog/passkeys-stakeholder) da indústria de [pagamentos](https://www.corbado.com/pt/blog/credenciais-digitais-pagamentos) para desenvolver e impulsionar a adoção de padrões de segurança de dados e recursos para [pagamentos](https://www.corbado.com/pt/blog/credenciais-digitais-pagamentos) seguros em todo o mundo. Além do PCI DSS, o Conselho gere uma [série de padrões](https://en.wikipedia.org/wiki/Payment_Card_Industry_Security_Standards_Council) que abordam vários aspetos da [segurança de pagamentos](https://www.corbado.com/pt/blog/passkeys-da-visa). A sua missão é melhorar a segurança global dos dados de contas de pagamento, desenvolvendo padrões e serviços de apoio que [promovam a educação, a consciencialização e a implementação eficaz](https://www.researchgate.net/publication/385008508_Achieving_PCI-DSS_Compliance_in_Payment_Gateways_A_Comprehensive_Approach) por parte dos [stakeholders](https://www.corbado.com/blog/passkeys-stakeholder). ### 2.3 Evolução para o PCI DSS 4.0: Principais Impulsionadores e Objetivos Os [Padrões PCI DSS 4.0](https://www.commerce.uwo.ca/pdf/PCI-DSS-v4_0.pdf), oficialmente lançados em março de 2022, [com uma revisão menor subsequente (v4.0.1) para abordar o feedback dos stakeholders](https://www.middlebury.edu/sites/default/files/2025-01/PCI-DSS-v4_0_1.pdf), marcam a atualização mais significativa do padrão em anos. O principal impulsionador desta evolução foi a necessidade de abordar o cenário de ameaças cibernéticas cada vez mais sofisticado e o ambiente tecnológico em mudança na indústria de [pagamentos](https://www.corbado.com/pt/blog/credenciais-digitais-pagamentos). Os objetivos centrais do PCI DSS 4.0 são: - **Atender às necessidades de segurança em evolução da indústria de pagamentos:** Garantir que o padrão permaneça eficaz contra ameaças atuais e emergentes, como o [phishing](https://www.corbado.com/glossary/phishing) baseado em IA. - **Promover a segurança como um processo contínuo:** Mudar o foco da conformidade pontual para uma [disciplina de segurança contínua](https://www.fortra.com/resources/guides/pci-dss-4-compliance). - **Melhorar os métodos e procedimentos de validação:** Aumentar o rigor e a consistência das avaliações de conformidade. - **Adicionar flexibilidade e apoiar metodologias adicionais:** Permitir que as organizações tenham mais liberdade na forma como alcançam os objetivos e resultados de segurança. ### 2.4 Mudanças Centrais na Versão 4.0: Foco nos Resultados de Segurança, Segurança Contínua, Implementação Personalizada e Prazos de Transição O [PCI DSS 4.0 introduz](https://www.middlebury.edu/sites/default/files/2025-01/PCI-DSS-v4_0_1.pdf) várias mudanças fundamentais que impactam a forma como as organizações abordam a conformidade: **Foco nos Resultados de Segurança vs. Controlos Prescritivos** Uma mudança crucial é a transição de controlos primariamente prescritivos para uma ênfase nos resultados de segurança. O próprio padrão elabora sobre esta flexibilidade: > _Secção 8: Abordagens para Implementar e Validar o PCI DSS_ > > Para apoiar a flexibilidade na forma como os objetivos de segurança são alcançados, > existem duas abordagens para implementar e validar o PCI DSS. > > A Abordagem Personalizada foca-se no Objetivo de cada requisito do PCI DSS, permitindo > que as entidades implementem controlos para cumprir o Objetivo declarado do requisito de > uma forma que não siga estritamente o requisito definido. Esta mudança significa que, enquanto o PCI DSS 3.2.1 oferecia instruções detalhadas sobre _o que_ fazer, a versão 4.0 permite às organizações mais flexibilidade sobre _como_ cumprem os requisitos. As empresas podem implementar os controlos mais adequados ao seu ambiente, desde que possam demonstrar que esses controlos alcançam os objetivos de segurança declarados. Isto é particularmente relevante para a adoção de tecnologias inovadoras como as passkeys, que poderiam não se encaixar perfeitamente em descrições de controlo mais antigas e rígidas. Esta flexibilidade, no entanto, vem com a expectativa de que as organizações realizem avaliações de risco completas e justifiquem claramente as suas metodologias de controlo escolhidas. **Segurança Contínua (Business-as-Usual)** Outro princípio fundamental no PCI DSS 4.0 é a promoção da segurança como um processo contínuo, de rotina (business-as-usual - BAU). O padrão detalha isto na Secção 5: > _Secção 5: Melhores Práticas para Implementar o PCI DSS em Processos de Rotina_ > > Uma entidade que implementa processos de rotina... está a tomar medidas para garantir > que os controlos de segurança... continuam a ser implementados corretamente e a > funcionar adequadamente como parte normal do negócio. > > Alguns requisitos do PCI DSS destinam-se a atuar como processos BAU, monitorizando os > controlos de segurança para garantir a sua eficácia de forma contínua. Esta ênfase em processos "business-as-usual" (BAU) significa que as organizações devem incorporar a segurança nas suas atividades de rotina. Trata-se de fomentar uma cultura onde a segurança não é uma reflexão tardia ou uma corrida anual, mas uma parte integrante das operações, garantindo monitorização contínua, avaliações regulares e posturas de segurança adaptativas para assegurar a proteção sustentada dos dados dos titulares de cartão. Para implementações de passkeys, isto traduz-se em vigilância contínua na monitorização da sua eficácia, padrões de adoção pelos utilizadores e quaisquer ameaças emergentes, tornando a segurança um esforço sustentado em vez de um exercício de conformidade pontual. **Implementação Personalizada e Análise de Risco Direcionada** Uma nova característica significativa no PCI DSS 4.0 é a opção formalizada para [implementação personalizada](https://blog.pcisecuritystandards.org/pci-dss-v4-0-compensating-controls-vs-customized-approach), que está intrinsecamente ligada a uma rigorosa avaliação de risco. O padrão exige esta ligação no Requisito 12.3.2: > _Requisito 12.3.2: Apoiar a Segurança da Informação com Políticas e Programas > Organizacionais_ > > Uma análise de risco direcionada é realizada para cada requisito do PCI DSS que a > entidade cumpre com a abordagem personalizada, para incluir... evidência documentada... > aprovação pela gestão sénior, e a realização da análise de risco direcionada pelo menos > uma vez a cada 12 meses. Esta opção formalizada permite que as organizações cumpram os objetivos de segurança usando novas tecnologias e controlos inovadores adaptados aos seus ambientes únicos, em vez de aderirem estritamente a métodos prescritivos. No entanto, como a citação enfatiza, esta flexibilidade baseia-se na realização de uma análise de risco direcionada para cada controlo personalizado. Esta análise deve ser documentada, aprovada pela gestão sénior e revista anualmente. Um avaliador terceiro (Qualified Security Assessor ou QSA) valida então estes controlos personalizados, revendo a abordagem documentada da organização, incluindo a análise de risco, e desenvolvendo procedimentos de teste específicos. Este caminho é um facilitador chave para soluções como as passkeys, permitindo que as organizações aproveitem as suas funcionalidades de segurança avançadas de forma eficaz, desde que possam demonstrar, através da avaliação de risco, que a sua abordagem cumpre os objetivos de segurança. A capacidade de personalizar a implementação, apoiada por uma análise de risco robusta, reflete um entendimento de que a rápida evolução tanto das ameaças como das tecnologias de defesa torna os controlos rígidos e prescritivos menos adaptáveis ao longo do tempo. **Prazos de Transição** O PCI DSS 3.2.1 permaneceu ativo juntamente com a v4.0 até 31 de março de 2024, após o qual foi retirado. Os novos requisitos introduzidos no PCI DSS 4.0 foram considerados melhores práticas até 31 de março de 2025. Após esta data, estes novos requisitos tornam-se obrigatórios para todas as avaliações. Esta abordagem faseada proporcionou às organizações uma janela para compreender, planear e implementar as mudanças. Estas mudanças, em conjunto, sinalizam uma abordagem mais madura, adaptável e focada no risco para a segurança dos cartões de pagamento, preparando o terreno para a adoção de mecanismos de autenticação mais fortes e modernos. ## 3. Os Riscos São Altos: Implicações da Não Conformidade com o PCI DSS A falha em cumprir os requisitos do PCI DSS não é apenas um descuido; acarreta consequências significativas e multifacetadas que podem impactar severamente a estabilidade financeira, a posição legal e a reputação de uma organização. ### 3.1 Penalidades Financeiras A consequência mais direta da não conformidade é a imposição de [penalidades financeiras](https://www.securitycompass.com/blog/pci-non-compliance-fees/). Estas multas são tipicamente aplicadas pelos bancos adquirentes e processadores de pagamento, não diretamente pelo [PCI SSC](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys). As penalidades podem ser substanciais, variando de [$5.000 a $100.000 por mês](https://www.ixopay.com/blog/5-consequences-of-pci-noncompliance), dependendo do volume de transações processadas (que determina o nível do [merchant](https://www.corbado.com/glossary/merchant), por exemplo, Nível 1 para mais de 6 milhões de transações anuais vs. Nível 4 para menos de 20.000 transações de [e-commerce](https://www.corbado.com/passkeys-for-e-commerce)) e da duração e gravidade da não conformidade. Por exemplo, um [merchant](https://www.corbado.com/glossary/merchant) de Nível 1 não conforme por vários meses tem maior probabilidade de enfrentar penalidades no extremo superior desta faixa, enquanto empresas menores de Nível 4 podem incorrer em multas mais próximas de $5.000 mensais. É crucial entender que estas multas podem ser um [encargo mensal recorrente](https://www.ixopay.com/blog/5-consequences-of-pci-noncompliance). Esta pressão financeira persistente, potencialmente agravada por [taxas de transação aumentadas](https://www.securitycompass.com/blog/pci-non-compliance-fees/) que os processadores de pagamento podem cobrar a empresas não conformes, significa que o [custo](https://www.corbado.com/pt/blog/custos-sms) cumulativo da _não conformidade_ excede em muito o investimento necessário para _alcançar e manter a conformidade_. Isto reformula a conformidade não como um mero centro de custos, mas como um investimento crítico na mitigação de riscos. Investir em medidas de segurança robustas, incluindo autenticação forte como as passkeys, torna-se uma decisão financeiramente prudente para evitar estes custos maiores, muitas vezes imprevisíveis e potencialmente incapacitantes. ### 3.2 Repercussões Legais e Regulatórias Além das multas diretas, a não conformidade pode levar a sérios desafios legais, especialmente se resultar numa violação de dados. Os clientes cujos dados são comprometidos podem iniciar processos judiciais, e as marcas de cartão também podem tomar medidas legais. Um estado de não conformidade pode tornar consideravelmente mais fácil para os queixosos demonstrarem negligência por parte da organização, levando potencialmente a acordos e sentenças dispendiosas. ### 3.3 Danos à Reputação e Perda de Confiança do Cliente Talvez uma das consequências mais prejudiciais, embora menos quantificável, seja o dano à reputação de uma organização. Uma única falha de conformidade, particularmente uma que leve a uma violação de dados, pode erodir severamente a confiança do cliente. Uma vez perdida, esta confiança é difícil de recuperar, resultando frequentemente na perda de clientes, perda de negócios para concorrentes e danos a longo prazo à imagem da marca. Violações repetidas ou graves podem até levar à [revogação dos privilégios de processamento de pagamentos de uma organização](https://www.securitycompass.com/blog/pci-non-compliance-fees/) pelas marcas de cartão ou bancos adquirentes, cortando efetivamente a sua capacidade de aceitar pagamentos com cartão. Isto sublinha a importância de ver a conformidade não apenas como um requisito técnico, mas como um componente fundamental da confiança na marca e da continuidade dos negócios. ### 3.4 Custos de Compensação por Violação de Dados Se a não conformidade contribuir para uma violação de dados, a organização será provavelmente responsável por custos de compensação substanciais, além de multas e taxas legais. Estes custos podem incluir o fornecimento aos clientes afetados de serviços como monitorização de crédito gratuita, [seguro](https://www.corbado.com/passkeys-for-insurance) contra roubo de identidade e reembolso por cobranças fraudulentas ou taxas de serviço. Além disso, o [custo](https://www.corbado.com/pt/blog/custos-sms) de reemissão de cartões de pagamento comprometidos, estimado entre $3 a $5 por cartão, pode rapidamente escalar para milhões de dólares em violações que afetam um grande número de titulares de cartão. Por outro lado, se uma organização sofrer uma violação enquanto estiver totalmente em conformidade com o PCI DSS, as multas associadas podem ser reduzidas ou até eliminadas, pois a conformidade demonstra a devida diligência e um compromisso com a segurança, em vez de negligência. A gama de potenciais resultados negativos destaca que a conformidade com o PCI DSS é um aspeto indispensável das operações comerciais modernas para qualquer entidade envolvida no ecossistema de cartões de pagamento. ## 4. Controlos de Autenticação Reforçados do PCI DSS 4.0: Um Olhar Mais Atento ao Requisito 8 O Requisito 8 do PCI DSS sempre foi uma pedra [angular](https://www.corbado.com/blog/angular-passkeys) do padrão. Com a versão 4.0, as suas estipulações foram significativamente fortalecidas, refletindo o papel crítico da autenticação robusta na prevenção do acesso não autorizado a dados sensíveis de titulares de cartão e aos sistemas que os processam. ### 4.1 Visão Geral do Requisito 8: Identificar e Autenticar o Acesso aos Componentes do Sistema O objetivo principal do Requisito 8 é garantir que cada indivíduo que acede a componentes do sistema dentro do Ambiente de Dados do Titular do Cartão (CDE) ou conectado a ele possa ser identificado de forma única e autenticado de forma robusta. Isto é importante para manter a integridade e a segurança dos dados do titular do cartão, prevenindo o acesso não autorizado e garantindo que todas as ações possam ser rastreadas até um utilizador específico e conhecido, estabelecendo assim a responsabilidade individual. ### 4.2 Mandatos de Autenticação Multifator (MFA) Fortalecidos Uma grande evolução no PCI DSS 4.0 é a expansão e fortificação dos requisitos de Autenticação Multifator (MFA): - **MFA Universal para Acesso ao CDE:** Ao contrário do PCI DSS 3.2.1, que exigia principalmente MFA para acesso administrativo e todo o acesso remoto ao CDE, a versão 4.0 exige MFA para _todo_ o acesso ao CDE. Isto inclui o acesso por administradores, utilizadores gerais e fornecedores terceiros, independentemente de o acesso se originar de dentro ou de fora da rede. Esta expansão significativa sublinha o reconhecimento do [PCI SSC](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) da MFA como um controlo de segurança fundamental.\ O padrão especifica estes requisitos: > _Excertos do Requisito 8_ > > "8.4.1 A MFA é implementada para todo o acesso não-consola ao CDE para pessoal com > acesso administrativo."  > > "8.4.3 A MFA é implementada para todo o acesso remoto originado de fora da rede da > entidade que possa aceder ou impactar o CDE."  - **Requisitos de Fator:** As implementações de MFA devem usar pelo menos dois dos três tipos de fatores de autenticação reconhecidos: - Algo que você sabe (ex: senha, PIN) - Algo que você tem (ex: um dispositivo token, [smart card](https://www.corbado.com/glossary/smart-card), ou um dispositivo que contém uma passkey) - Algo que você é (ex: dados biométricos como uma impressão digital ou reconhecimento facial). Crucialmente, estes fatores devem ser independentes, o que significa que o comprometimento de um fator não compromete os outros. - **Integridade do Sistema MFA:** Os sistemas de MFA devem ser projetados para resistir a ataques de repetição (onde um atacante interceta e reutiliza dados de autenticação) e devem conceder acesso apenas após todos os fatores de autenticação necessários terem sido validados com sucesso. - **Sem Bypass Não Autorizado:** A MFA não deve ser contornável por nenhum utilizador, incluindo administradores, a menos que uma exceção específica e documentada seja concedida pela gestão, por instância, por um período de tempo limitado. - **Autenticação Resistente a Phishing como Exceção:** O PCI DSS 4.0 também introduz orientações adicionais sobre fatores de autenticação resistentes a [phishing](https://www.corbado.com/glossary/phishing), que podem, em alguns casos, cumprir a intenção da MFA. > _Excertos do Requisito 8_ > > "Este requisito não se aplica a... contas de utilizador que são autenticadas apenas > com fatores de autenticação resistentes a [phishing](https://www.corbado.com/glossary/phishing)." — Notas > de Aplicabilidade para 8.4.2  > > "Autenticação [resistente a phishing](https://www.corbado.com/pt/blog/como-eliminar-senhas-por-completo)... > Exemplos de autenticação resistente a phishing incluem [FIDO2](https://www.corbado.com/glossary/fido2)." — > Apêndice G, Definição do Glossário de Autenticação > [Resistente a Phishing](https://www.corbado.com/pt/blog/como-eliminar-senhas-por-completo)  As implicações da autenticação resistente a phishing, como destacado por estes excertos, serão exploradas mais a fundo na próxima secção (4.3). ### 4.3 Ênfase na Autenticação Resistente a Phishing O PCI DSS 4.0 coloca uma ênfase notável no uso de métodos de autenticação resistentes a phishing. Esta é uma resposta direta à prevalência e sucesso dos ataques de phishing no comprometimento de credenciais tradicionais. - **Autenticação Resistente a Phishing como Alternativa/Complemento à MFA:** - Um desenvolvimento crítico sob o Requisito 8.4.2 é que os métodos de autenticação resistentes a phishing podem ser usados [_em vez de_ MFA tradicional](https://blog.pcisecuritystandards.org/coffee-with-the-council-podcast-passwords-versus-passkeys-a-discussion-with-the-fido-alliance) para todo o acesso não administrativo ao CDE originado de dentro da rede da entidade. Esta é uma provisão significativa para tecnologias como as passkeys, que são inerentemente resistentes a phishing. Sinaliza que o PCI SSC vê estes métodos avançados como fornecendo um nível de garantia comparável ou até superior a algumas combinações de MFA tradicionais para este caso de uso específico. - **No entanto, para acesso administrativo ao CDE (Requisito 8.4.1) e para todo o acesso remoto originado de fora da rede da entidade para o CDE (Requisito 8.4.3), embora a autenticação resistente a phishing seja fortemente recomendada, ela [_deve ser combinada com pelo menos um outro fator de autenticação_](https://blog.pcisecuritystandards.org/coffee-with-the-council-podcast-passwords-versus-passkeys-a-discussion-with-the-fido-alliance) para cumprir o requisito de MFA.** Esta distinção necessita de uma abordagem matizada para a implementação de passkeys, potencialmente uma estratégia em camadas onde as passkeys sozinhas são suficientes para utilizadores internos gerais, mas as passkeys combinadas com outro fator são usadas para cenários de acesso de maior risco. - **Reconhecimento da FIDO e Perspetivas de Especialistas:** O padrão menciona especificamente a autenticação baseada em [FIDO](https://www.corbado.com/pt/glossary/attestation) (que sustenta as passkeys) como um método preferido para alcançar a MFA, em grande parte devido às suas robustas características de resistência a phishing. Mais informações sobre este tópico foram partilhadas no episódio do podcast do PCI SSC "Coffee with the Council", "Passwords Versus Passkeys: A Discussion with the [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance)" ([https://blog.pcisecuritystandards.org/coffee-with-the-council-podcast-passwords-versus-passkeys-a-discussion-with-the-fido-alliance](https://blog.pcisecuritystandards.org/coffee-with-the-council-podcast-passwords-versus-passkeys-a-discussion-with-the-fido-alliance)). No podcast, Andrew Jamieson, VP Distinguished Standards Architect no PCI SSC, enfatizou o valor destas tecnologias: > "Eu reiteraria que penso que a autenticação resistente a phishing é uma ótima > tecnologia. É algo que pode resolver muitos dos problemas que temos com as senhas. E > eu sugeriria fortemente que, quando as pessoas estiverem a analisar que tecnologias > vão implementar para autenticação, olhem para a autenticação resistente a phishing e > o que ela pode trazer, mas também compreendendo que é um pouco diferente do que as > pessoas estão habituadas e investigando como podem integrar isso corretamente e de > forma segura na sua arquitetura de autenticação geral." Megan Shamas, Chief Marketing Officer na [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance) (ver [Liderança da FIDO](https://fidoalliance.org/overview/leadership/)), destacou a mudança fundamental que estas tecnologias representam e a necessidade de as políticas se adaptarem: > "É fundamentalmente diferente do que estamos habituados com senhas mais fator, > fator, fator, e nós evoluímos a tecnologia e agora as pessoas precisam também de > evoluir os seus requisitos e as suas políticas juntamente com isso. E isso realmente > ajudará as organizações a entrar no caminho certo para se livrarem da autenticação > suscetível a phishing." Esta perspetiva conjunta sublinha o movimento da indústria em direção a métodos de autenticação mais seguros e modernos. ### 4.4 Novos Requisitos de Senha e Frase-passe (se usadas) Embora o PCI DSS 4.0 incentive fortemente o uso de MFA e métodos resistentes a phishing, também aperta os requisitos para senhas e frases-passe se ainda estiverem em uso: - **Comprimento e Complexidade Aumentados:** O comprimento mínimo da senha foi aumentado de sete caracteres na v3.2.1 para 12 caracteres na v4.0 (ou pelo menos 8 caracteres se o sistema não suportar 12). As senhas também devem incluir uma mistura de caracteres numéricos e alfabéticos. - **Frequência de Alteração de Senha:** As senhas devem ser alteradas pelo menos a cada 90 dias se forem o _único_ fator usado para autenticação (ou seja, nenhuma MFA é aplicada a essa conta para esse acesso). Este requisito pode ser dispensado se a MFA for implementada para o acesso, ou se a organização empregar autenticação contínua baseada em risco que avalia dinamicamente o acesso em tempo real. O fortalecimento significativo das regras de senha, juntamente com os mandatos de MFA expandidos e o claro endosso de abordagens resistentes a phishing, sinaliza uma direção estratégica do PCI SSC: reduzir sistematicamente a dependência de senhas como mecanismo de autenticação primário ou único. As senhas há muito são reconhecidas como um elo fraco na segurança, e o PCI DSS 4.0 procura ativamente mitigar os seus riscos inerentes, tornando o seu uso isolado mais rigoroso e menos atrativo, ao mesmo tempo que promove alternativas mais fortes e modernas. Para ilustrar claramente estas mudanças, a tabela seguinte compara aspetos chave da autenticação entre o PCI DSS 3.2.1 e 4.0: **Tabela 1: Principais Diferenças na Autenticação: PCI DSS 3.2.1 vs. 4.0** | Característica | PCI DSS 3.2.1 | PCI DSS 4.0 | | :----------------------------------- | :------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **MFA para Acesso ao CDE** | Obrigatória para acesso administrativo não-consola e todo o acesso remoto ao CDE. | Obrigatória para [**todo** o acesso ao CDE](https://drata.com/blog/pci-dss-v4-0) (administrativo, não administrativo, interno, remoto). | | **Comprimento da Senha (Mínimo)** | 7 caracteres (numéricos e alfabéticos). | 12 caracteres (numéricos e alfabéticos); 8 se o sistema não suportar 12. | | **Frequência de Alteração de Senha** | A cada 90 dias. | A cada 90 dias [**se a senha for o único fator**](https://www.securitymetrics.com/blog/password-updates-and-requirements-in-pci-4); pode ser mais longo se for usada MFA ou autenticação baseada em risco. | | **Ênfase na Resistência a Phishing** | Limitada, abordada principalmente através da consciencialização geral sobre segurança. | Forte ênfase; a autenticação resistente a phishing pode substituir a MFA para certos acessos internos ao CDE (Req 8.4.2). FIDO explicitamente mencionado. | | **Uso de Passkeys/FIDO** | Não abordado explicitamente como um método primário. | Autenticação baseada em FIDO citada como um método de MFA preferido. Métodos resistentes a phishing (como passkeys) recebem papéis específicos no cumprimento dos requisitos de MFA. | Este foco intensificado na autenticação no PCI DSS 4.0 estabelece uma direção clara para as organizações reavaliarem as suas estratégias atuais e explorarem soluções mais resilientes como as passkeys. ## 5. Passkeys: O Futuro da Autenticação Resistente a Phishing Baseadas nos padrões da [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance), as passkeys oferecem uma alternativa fundamentalmente mais segura e fácil de usar do que as senhas tradicionais e até mesmo algumas formas de MFA legadas. ### 5.1 O que são Passkeys? (padrões FIDO, WebAuthn) Uma passkey é uma credencial digital que permite aos utilizadores iniciar sessão em websites e aplicações sem a necessidade de inserir uma senha. Elas são construídas sobre os padrões [FIDO2](https://www.corbado.com/glossary/fido2), um conjunto de especificações abertas desenvolvidas pela FIDO Alliance. O WebAuthn é um padrão do World Wide Web Consortium (W3C) que permite que navegadores e aplicações web realizem autenticação forte e resistente a phishing usando pares de chaves criptográficas. Essencialmente, as passkeys são uma implementação destes padrões [FIDO2](https://www.corbado.com/glossary/fido2), aproveitando o WebAuthn para interações em ambientes web. Elas substituem as senhas tradicionais por chaves criptográficas únicas armazenadas de forma segura no dispositivo de um utilizador, como um smartphone, computador ou [chave de segurança](https://www.corbado.com/pt/blog/melhores-fido2-chaves-de-seguranca-hardware) de hardware. ### 5.2 Como as Passkeys Funcionam: Criptografia, Vinculação ao Dispositivo, Biometria/PIN A segurança das passkeys está enraizada na [criptografia de chave pública](https://www.corbado.com/pt/blog/webauthn-pubkeycredparams-credentialpublickey). Quando um utilizador regista uma passkey num serviço (a "[relying party](https://www.corbado.com/glossary/relying-party)" ou RP), é gerado um par de chaves criptográficas único: - Uma **chave privada**, que é armazenada de forma segura no dispositivo do utilizador. Esta chave pode residir dentro de um módulo de segurança de hardware (ex: um TPM ou [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)). A chave privada nunca sai deste armazenamento seguro (exceto no caso de passkeys sincronizadas, como será detalhado mais tarde). - Uma **chave pública**, que é enviada e armazenada pela [relying party](https://www.corbado.com/glossary/relying-party) (o website ou serviço de aplicação) e associada à conta do utilizador. Durante a autenticação, o processo é o seguinte: 1. A [relying party](https://www.corbado.com/glossary/relying-party) envia um "desafio" único (um pedaço de dados aleatório) para o dispositivo do utilizador. 2. Para desbloquear e usar a chave privada, o utilizador realiza uma verificação local no seu dispositivo. Isto envolve tipicamente o uso de um identificador biométrico (como uma impressão digital ou scan facial), a inserção de um PIN do dispositivo, ou o desenho de um padrão. Importante, estes dados biométricos ou PIN nunca saem do dispositivo do utilizador e não são transmitidos para a relying party. 3. Uma vez desbloqueada, a chave privada no dispositivo assina o desafio recebido da relying party. 4. Este desafio assinado (a "asserção") é enviado de volta para a relying party. 5. A relying party usa a [chave pública](https://www.corbado.com/pt/glossary/jwks) armazenada correspondente a esse utilizador para verificar a assinatura na asserção. Se a assinatura for válida, a autenticação é bem-sucedida. Existem principalmente dois tipos de passkeys: - **Passkeys Sincronizadas:** Estas passkeys podem ser sincronizadas entre os dispositivos de confiança de um utilizador usando gestores de credenciais baseados na nuvem, como o [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) da Apple ou o [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager). Isto proporciona conveniência, permitindo que uma passkey criada num dispositivo seja usada noutro dispositivo pertencente ao mesmo utilizador dentro do mesmo ecossistema. - **Passkeys Vinculadas ao Dispositivo:** Estas passkeys estão ligadas a um autenticador físico específico, como uma [chave de segurança](https://www.corbado.com/pt/blog/melhores-fido2-chaves-de-seguranca-hardware) de hardware USB (ex: [YubiKey](https://www.corbado.com/glossary/yubikey)) ou uma aplicação num telemóvel específico. A passkey não sai deste dispositivo específico. Esta base criptográfica e o processo de verificação do utilizador local proporcionam benefícios de segurança inerentes que abordam diretamente muitos vetores de ataque comuns. ### 5.3 Benefícios de Segurança Inerentes: Resistência a Phishing, Sem Segredos Partilhados, Proteção Contra Credential Stuffing e Account Takeover (ATO) O design das passkeys oferece várias vantagens de segurança sobre os métodos de autenticação tradicionais: - **Resistência a Phishing:** Este é um benefício fundamental. As passkeys estão criptograficamente ligadas à origem específica do website (o Relying Party ID ou RP ID) para a qual foram criadas. Se um utilizador for enganado a visitar um site de phishing falso que imita um legítimo, o navegador ou sistema operativo reconhecerá que o domínio atual não corresponde ao RP ID associado à passkey. Como resultado, a passkey simplesmente não funcionará e a autenticação falhará. Isto transfere o fardo de identificar tentativas de phishing do utilizador humano, muitas vezes [fal](https://www.corbado.com/glossary/fal)ível, para os robustos protocolos de segurança da própria tecnologia. - **Sem Segredos Partilhados:** Com as passkeys, não há um "segredo partilhado" como uma senha que é conhecida tanto pelo utilizador como pelo servidor, e que pode ser roubada. A chave privada, que é o componente crítico para a autenticação, nunca sai do dispositivo seguro do utilizador. A [chave pública](https://www.corbado.com/pt/glossary/jwks), armazenada pelo servidor, está matematicamente ligada à chave privada, mas não pode ser usada para derivar a chave privada ou para se fazer passar pelo utilizador. Isto significa que, mesmo que o servidor de uma relying party seja violado e as chaves públicas sejam roubadas, elas são inúteis para os atacantes sem as chaves privadas correspondentes. - **Proteção Contra Credential Stuffing e Ataques de Repetição:** Os ataques de Credential stuffing, onde os atacantes usam listas de nomes de utilizador e senhas roubados para tentar obter acesso a várias contas, são tornados ineficazes porque não há senhas para roubar e reutilizar. Além disso, cada autenticação com passkey envolve um mecanismo único de desafio-resposta. A assinatura gerada pela chave privada é específica para o desafio recebido para essa sessão de login em particular, tornando impossível para um atacante intercetar uma asserção de autenticação e reproduzi-la mais tarde para obter acesso não autorizado. - **Redução significativa do risco de Account Takeover (ATO):** Ao neutralizar eficazmente o phishing, eliminar segredos partilhados e prevenir ataques de [credential stuffing](https://www.corbado.com/glossary/credential-stuffing) e de repetição, as passkeys reduzem drasticamente os principais vetores de ataque usados para a tomada de controlo de contas. Como os atacantes não conseguem obter ou usar indevidamente as credenciais de autenticação do utilizador, a probabilidade de um ATO bem-sucedido diminui drasticamente. Esta mudança fundamental da autenticação baseada no conhecimento (o que um utilizador sabe, como uma senha) para uma combinação de autenticação baseada na posse (o que um utilizador tem – o seu dispositivo com a chave segura) e baseada na inerência ou no conhecimento local (o que um utilizador é via [biometria](https://www.corbado.com/pt/blog/biometria-confirmacao-pagador), ou o que ele sabe localmente via PIN do dispositivo) quebra fundamentalmente as cadeias de ataque que dependem do comprometimento de segredos partilhados utilizáveis remotamente. Ao contrário de muitas medidas de segurança que adicionam atrito, as passkeys muitas vezes melhoram a experiência do utilizador, oferecendo logins mais rápidos e simples sem a necessidade de lembrar senhas complexas, um benefício duplo que pode impulsionar a adoção e melhorar a postura de segurança geral. ## 6. Construindo a Ponte: Como as Passkeys Satisfazem os Controlos de Autenticação do PCI DSS 4.0 As fortes características de segurança inerentes às passkeys alinham-se notavelmente bem com os controlos de autenticação reforçados exigidos pelo PCI DSS 4.0, particularmente os delineados no Requisito 8. As passkeys não só cumprem estes requisitos, como muitas vezes excedem a segurança fornecida pelos métodos tradicionais. ### 6.1 Abordando Diretamente os Critérios de MFA e Resistência a Phishing do Requisito 8 As passkeys satisfazem inerentemente os princípios centrais da Autenticação Multifator conforme definido pelo PCI DSS 4.0: - **Natureza Multifator:** Um evento de autenticação com passkey combina tipicamente "algo que você tem" (o dispositivo físico que contém a chave privada, como um smartphone ou [chave de segurança](https://www.corbado.com/pt/blog/melhores-fido2-chaves-de-seguranca-hardware) de hardware) com "algo que você é" (uma [biometria](https://www.corbado.com/pt/blog/biometria-confirmacao-pagador) como impressão digital ou scan facial usada para desbloquear a passkey no dispositivo) ou "algo que você sabe" (um PIN ou padrão do dispositivo). Estes fatores são independentes; comprometer um PIN do dispositivo, por exemplo, não compromete inerentemente a chave criptográfica se o próprio dispositivo permanecer seguro. - **Resistência a Phishing:** Como amplamente discutido, as passkeys são resistentes a phishing por design devido à sua natureza criptográfica e vinculação à origem. A chave privada nunca é exposta à relying party ou transmitida pela rede, e a passkey só funcionará no domínio legítimo para o qual foi registada. Isto alinha-se diretamente com a forte ênfase do PCI DSS 4.0 na mitigação de ameaças de phishing. - **Resistência a Replay:** Cada autenticação com passkey envolve um desafio criptográfico único do servidor, que é então assinado pela chave privada. A assinatura resultante é válida apenas para esse desafio e sessão específicos, tornando-a resistente a ataques de repetição. Isto cumpre o Requisito 8.5, que exige que os sistemas de MFA previnam tais ataques. ### 6.2 Superando a Segurança Baseada em Senhas Tradicionais Comparadas com as senhas tradicionais, as passkeys oferecem um modelo de segurança vastamente superior. As senhas são vulneráveis a uma multitude de ataques: phishing, engenharia social, [credential stuffing](https://www.corbado.com/glossary/credential-stuffing) devido à reutilização de senhas, ataques de força bruta e roubo de bases de dados violadas. As passkeys eliminam estas vulnerabilidades removendo completamente o segredo partilhado (a senha) da equação. A autenticação depende da prova criptográfica de posse de uma chave privada, que por sua vez é protegida pela segurança local do dispositivo, em vez de um segredo que pode ser facilmente roubado ou adivinhado. ### 6.3 A Perspetiva do PCI SSC sobre as Passkeys O Conselho de Padrões de Segurança do [PCI](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) reconheceu o potencial da tecnologia de passkeys. Informações do podcast do PCI SSC ["Coffee with the Council"](https://blog.pcisecuritystandards.org/coffee-with-the-council-podcast-passwords-versus-passkeys-a-discussion-with-the-fido-alliance) com uma discussão com a FIDO Alliance fornecem clareza sobre a sua posição: - Para acesso não administrativo ao Ambiente de Dados do Titular do Cartão (CDE) de _dentro_ da rede da entidade (Requisito 8.4.2), o PCI SSC indica que métodos de autenticação resistentes a phishing como as passkeys podem ser usados _em vez de_ MFA tradicional. Este é um reconhecimento significativo da força das passkeys. - Para acesso administrativo ao CDE (Requisito 8.4.1) e para qualquer acesso remoto à rede (Requisito 8.4.3), embora as passkeys (como autenticação resistente a phishing) sejam recomendadas, elas _devem ser usadas em conjunto com outro fator de autenticação_ para satisfazer o requisito de MFA. Isto sugere uma abordagem baseada no risco, onde cenários de acesso de maior privilégio ou maior risco exigem uma camada adicional. - O PCI SSC está a desenvolver ativamente orientações, como FAQs, para ajudar as organizações a entender como [implementar passkeys](https://www.corbado.com/pt/blog/tutorial-passkeys-como-implementar-em-apps-web) de maneira compatível e reconhece que as passkeys representam uma mudança fundamental em relação ao pensamento tradicional baseado em senhas. - Além disso, a documentação do PCI DSS 4.0 referencia explicitamente a autenticação baseada em [FIDO](https://www.corbado.com/pt/glossary/attestation) como um método preferido, embora não obrigatório, para implementar MFA, sublinhando o seu alinhamento com os objetivos do padrão. Esta posição permite que as organizações implementem passkeys estrategicamente. Para a base ampla de utilizadores não administrativos que acedem ao CDE internamente, um [login com passkey](https://www.corbado.com/pt/blog/aumentar-adocao-login-passkeys) fluido pode cumprir os requisitos de conformidade. Para administradores e utilizadores remotos, as passkeys fornecem uma base forte e resistente a phishing para uma solução de MFA. ### 6.4 Tipos de Passkey, Independência de Fatores e Attestation: Navegando nas Expectativas do QSA para o Requisito 8 Embora as passkeys ofereçam uma atualização de segurança significativa, os Qualified Security Assessors (QSAs) do PCI DSS irão escrutinar a sua implementação, especialmente para cenários de acesso de alto risco como o acesso administrativo ao CDE (Requisito 8.4.1), para garantir que os verdadeiros princípios de autenticação multifator são cumpridos. As principais considerações incluem o tipo de passkey, a independência dos fatores de autenticação e o uso de [attestation](https://www.corbado.com/glossary/attestation). #### 6.4.1 Passkeys Sincronizadas vs. Vinculadas ao Dispositivo: Como já discutimos, as passkeys existem em duas formas principais: - _Passkeys Sincronizadas:_ São sincronizadas entre os dispositivos de confiança de um utilizador através de serviços na nuvem como o [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) da Apple ou o Google [Password Manager](https://www.corbado.com/blog/passkeys-vs-password-managers). Oferecem conveniência, pois uma passkey criada num dispositivo pode ser usada noutro. - _Passkeys Vinculadas ao Dispositivo:_ Estão ligadas a um autenticador físico específico, como uma chave de segurança de hardware USB (ex: [YubiKey](https://www.corbado.com/glossary/yubikey)) ou um hardware seguro de um telemóvel específico. A chave privada não sai deste dispositivo específico. #### 6.4.2 Independência de Fatores e Escrutínio do QSA O PCI DSS exige que os fatores de MFA sejam independentes, o que significa que o comprometimento de um fator não compromete os outros. Uma passkey combina tipicamente "algo que você tem" (o dispositivo com a chave privada) e "algo que você sabe/é" (o PIN do dispositivo local ou [biometria](https://www.corbado.com/pt/blog/biometria-confirmacao-pagador) para desbloquear a chave). Com as passkeys sincronizadas, embora altamente seguras contra muitos ataques, alguns QSAs podem levantar questões sobre a independência absoluta do fator de "posse" para acesso administrativo (Requisito 8.4.1). A preocupação é que, se a conta na nuvem do utilizador (ex: Apple ID, conta Google) que sincroniza as passkeys for comprometida, a chave privada poderia potencialmente ser clonada para um dispositivo controlado pelo atacante. Isto poderia levar alguns avaliadores a ver uma passkey sincronizada, em contextos de alto risco, como potencialmente não cumprindo a interpretação rigorosa de dois fatores totalmente independentes se o próprio mecanismo de sincronização não for robustamente protegido com a sua própria MFA forte. As diretrizes do [NIST](https://www.corbado.com/blog/nist-passkeys), por exemplo, reconhecem as passkeys sincronizadas como compatíveis com [AAL2](https://www.corbado.com/blog/nist-passkeys), enquanto as passkeys vinculadas ao dispositivo podem atingir [AAL3](https://www.corbado.com/blog/nist-passkeys), que muitas vezes envolvem chaves não exportáveis. - **Compreender as Flags do Autenticador WebAuthn:** Durante uma cerimónia WebAuthn (que sustenta as passkeys), os autenticadores reportam certas flags. Duas importantes são: - **uv=1 (User Verified - Utilizador Verificado):** Esta flag indica que o utilizador verificou com sucesso a sua presença no autenticador localmente, tipicamente usando um PIN do dispositivo ou biometria. Esta verificação atua como um dos fatores de autenticação – "algo que você sabe" (PIN) ou "algo que você é" (biometria). - **up=1 (User Present - Utilizador Presente):** Esta flag confirma que o utilizador esteve presente e interagiu com o autenticador durante a cerimónia (ex: tocando numa chave de segurança). Embora crucial para provar a intenção do utilizador e prevenir certos ataques remotos, a presença do utilizador em si geralmente não é considerada um fator de autenticação separado e independente para satisfazer o requisito multifator da MFA. É uma característica de segurança importante, mas normalmente não conta como um segundo _fator_ por si só. - **O Papel das Passkeys Vinculadas ao Dispositivo e Chaves de Segurança de Hardware:**\ Para acesso administrativo (Requisito 8.4.1) e outros cenários de alta garantia, as passkeys vinculadas ao dispositivo armazenadas em chaves de segurança de hardware oferecem um argumento mais forte para a independência de fatores. Como a chave privada é projetada para nunca sair do token de hardware, o fator "algo que você tem" está mais robustamente protegido contra clonagem via ataques baseados em software ou comprometimento de contas na nuvem. Isto torna-as uma opção preferida para muitas organizações que procuram satisfazer as rigorosas expectativas do QSA para MFA administrativa. #### 6.4.3 Attestation para Verificação do Autenticador O [Attestation](https://www.corbado.com/glossary/attestation) é uma funcionalidade no WebAuthn onde o autenticador fornece informações verificáveis sobre si mesmo (ex: a sua marca, modelo, estado de certificação, se é suportado por hardware) à relying party (o seu servidor FIDO) durante o processo de registo da passkey. - **Porque é importante para o PCI DSS:** O [Attestation](https://www.corbado.com/glossary/attestation) pode fornecer evidências cruciais aos QSAs de que os autenticadores a serem usados cumprem as políticas de segurança da organização e são genuinamente o que afirmam ser (ex: uma chave de segurança de hardware certificada). Isto pode ser particularmente importante ao demonstrar a força e a independência dos fatores de autenticação. - **Recomendação:** Para acesso de alta segurança como o acesso administrativo ao CDE, o uso de passkeys em chaves de segurança de hardware que suportam um attestation robusto é altamente recomendado. Isto permite que a organização imponha políticas sobre tipos de autenticadores aceitáveis e forneça provas mais fortes de conformidade. Na prática, para evitar atritos de auditoria para o Requisito 8.4.1, muitas empresas optam por emitir passkeys vinculadas ao dispositivo em chaves de segurança de hardware que oferecem fortes garantias de proteção de chave e potencialmente attestation. ### 6.5 Mapeando Passkeys para as Subcláusulas do Requisito 8 Para ilustrar claramente como as passkeys constroem a ponte e satisfazem os controlos detalhados no Requisito 8, a tabela seguinte mapeia características específicas das passkeys e características para subcláusulas relevantes, indicando a sua adequação para diferentes cenários. | Subcláusula do Req. 8 | Característica da Passkey | Como a Passkey Cumpre/Excede | Sincronizada OK? | Vinculada ao Dispositivo OK? | | :------------------------------- | :--------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------- | :--------------------------- | | 8.2 (ID de Utilizador) | ID de Utilizador Único via Passkey | Cada passkey é única para o registo de um utilizador num serviço. As chaves privadas não são partilhadas. Permite a responsabilidade individual. | ✅ | ✅ | | 8.3.x (Senhas) | Substituição de Senha | Se as passkeys substituírem completamente as senhas para um caminho de acesso, os controlos específicos de senha (comprimento, complexidade, rotação, histórico) tornam-se N/A para esse caminho, simplificando a conformidade para esses controlos. | ✅ | ✅ | | 8.4.1 (MFA Admin) | Fator Resistente a Phishing (Dispositivo + Local) | A passkey serve como um fator forte e resistente a phishing. (Escrutínio do QSA sobre a independência de fatores para passkeys sincronizadas). | ⚠️ | ✅ | | 8.4.2 (MFA Não-Consola) | Autenticação Resistente a Phishing (Dispositivo + Local) | A autenticação resistente a phishing (como as passkeys) pode ser usada _em vez de_ MFA tradicional para este cenário. | ✅ | ✅ | | 8.4.3 (MFA Remoto) | Fator Resistente a Phishing (Dispositivo + Local) | A passkey serve como um fator forte e resistente a phishing para a rede. (Escrutínio do QSA sobre a independência de fatores para passkeys sincronizadas). | ⚠️ | ✅ | | 8.5.1 (Resistência a Replay) | Desafio/Resposta Único | Cada login gera uma assinatura única ligada a um desafio do servidor, prevenindo a reutilização de dados de autenticação intercetados. | ✅ | ✅ | | 8.5.x (Independência de Fatores) | Fatores Locais Distintos (Dispositivo+Local) | A chave criptográfica no dispositivo e a biometria/PIN local são independentes. A operação criptográfica só prossegue após a verificação local bem-sucedida do utilizador. (A independência de fatores para chaves sincronizadas pode ser questionada pelos QSAs em cenários de alto risco). | ⚠️ | ✅ | | Resistência a Phishing (Geral) | Segurança Central (Vinculação à Origem, Sem Segredos, Criptografia PK) | Fundamentalmente projetada para resistir a ataques de phishing, garantindo que a passkey só funciona no site legítimo e que nenhum segredo que possa ser roubado é transmitido. | ✅ | ✅ | Este mapeamento demonstra que as passkeys não são apenas um ajuste teórico, mas uma solução prática e robusta para atender às exigências avançadas de autenticação do PCI DSS 4.0. ## 7. Conclusão: Adotar as Passkeys para uma Autenticação Forte O cenário da [segurança de pagamentos](https://www.corbado.com/pt/blog/passkeys-da-visa) é complexo e está em evolução. O PCI DSS 4.0 reflete esta realidade, estabelecendo um padrão mais elevado para os controlos de segurança, particularmente no domínio da autenticação. À medida que as organizações se esforçam para cumprir estas novas e mais rigorosas exigências, as passkeys — construídas sobre os padrões FIDO/WebAuthn — emergem não apenas como uma solução compatível, mas como uma tecnologia transformadora pronta para redefinir o acesso seguro. Ao longo desta análise, duas questões centrais guiaram a nossa exploração: 1. **Com o PCI DSS 4.0 a elevar o padrão de autenticação, como podem as organizações cumprir eficazmente estes novos e rigorosos requisitos sem sobrecarregar os utilizadores ou as equipas de segurança?** A evidência sugere fortemente que as organizações podem cumprir eficazmente os requisitos de autenticação do PCI DSS 4.0 adotando estrategicamente soluções de Autenticação Multifator (MFA) resistentes a phishing, como as passkeys. Estas tecnologias equilibram inerentemente uma segurança robusta e criptograficamente verificada com experiências de utilizador significativamente melhoradas e, muitas vezes, mais rápidas. Além disso, a permissão do PCI DSS 4.0 para "implementações personalizadas" capacita as organizações a adaptar tais soluções avançadas aos seus ambientes e perfis de risco específicos, superando uma abordagem de tamanho único. A própria orientação do PCI SSC facilita ainda mais isto, permitindo uma conformidade simplificada para um grande segmento de utilizadores, enquanto reserva abordagens mais estratificadas para acessos administrativos e remotos de maior risco. 2. **Podem tecnologias emergentes como as passkeys não só satisfazer os robustos controlos de autenticação do PCI DSS 4.0, mas também oferecer benefícios tangíveis para além da mera conformidade, como segurança aprimorada e eficiência operacional melhorada?** A resposta é um claro sim. As passkeys são comprovadamente capazes de satisfazer os controlos de autenticação centrais do Requisito 8 do PCI DSS 4.0, incluindo os seus critérios de MFA, resistência a phishing e resistência a replay. No entanto, o seu valor estende-se para além da mera conformidade. O design inerente das passkeys — eliminando segredos partilhados e vinculando a autenticação a origens específicas — reduz drasticamente o risco de ataques de phishing bem-sucedidos e de tomadas de controlo de contas, levando a reduções tangíveis em perdas relacionadas com fraudes. Operacionalmente, a transição para longe das senhas traduz-se em menos tickets de helpdesk relacionados com senhas, poupando custos e libertando recursos de TI. Os utilizadores beneficiam de uma experiência de login mais simples, rápida e menos frustrante, o que pode melhorar a produtividade e a satisfação do cliente. Além disso, onde as senhas são totalmente substituídas por passkeys para caminhos de acesso específicos, o fardo da auditoria para controlos específicos de senha é eliminado, potencialmente simplificando os esforços de conformidade nessas áreas. A jornada para um ecossistema de pagamentos verdadeiramente seguro é contínua. O PCI DSS 4.0 estabelece novos marcos, e a autenticação com passkeys fornece um veículo poderoso para os alcançar. As organizações que processam, armazenam ou transmitem dados de titulares de cartão são fortemente encorajadas a avaliar e a começar a planear a [adoção de passkeys](https://www.corbado.com/pt/blog/passkeys-adocao-business-case). Não se trata apenas de aderir à mais recente iteração de um padrão; trata-se de abraçar uma abordagem mais segura, eficiente e centrada no utilizador para a autenticação, que se alinha com o futuro da [identidade digital](https://www.corbado.com/pt/blog/credenciais-digitais-passkeys). Ao implementar estrategicamente as passkeys, as empresas podem fortalecer as suas defesas contra ameaças em evolução, proteger dados de pagamento valiosos e construir uma maior confiança com os seus clientes num mundo cada vez mais digital.