Em junho de 2026, o Banco Central publicou a versão 6.00 do Manual de Segurança do Sistema Financeiro Nacional (SFN), trazendo uma nova organização para os requisitos de segurança relacionados ao Pix e mudanças importantes em controles de acesso, certificados digitais e gestão de chaves criptográficas.
A atualização entrou em vigor em 8 de junho e trouxe também prazos específicos para alguns dos novos requisitos. Entre eles, uma data merece atenção especial: 6 de setembro de 2026, prazo de adequação no ambiente de produção para participantes que ainda utilizem certificados digitais em desconformidade com as novas regras da seção 5.1.
Mas o que efetivamente mudou? E o que as instituições devem observar agora?
A primeira mudança importante é estrutural.
Até então, os requisitos específicos de segurança relacionados ao Pix eram tratados no Manual de Segurança do Pix. Com a versão 6.00, esse conteúdo passou a integrar formalmente o Manual de Segurança do SFN como seu Volume II.
A estrutura passou a ser dividida da seguinte forma:
Volume I: Aspectos gerais de segurança
Reúne requisitos e recomendações relacionados à comunicação no âmbito do Sistema Financeiro Nacional, incluindo criptografia, protocolos, algoritmos e certificação digital.
Volume II: Segurança do Pix
Concentra os requisitos específicos de segurança do ecossistema Pix, contemplando o arranjo de pagamentos, o Sistema de Pagamentos Instantâneos (SPI), o DICT e os demais componentes e infraestruturas relacionados ao ecossistema.
Além dessa reorganização, a versão 6.00 introduziu três mudanças que merecem atenção especial:
| Mudança | O que significa na prática |
|---|---|
| Lista de IPs autorizados | O acesso à ICOM passa a depender também da origem previamente autorizada da conexão |
| Segregação de certificados | Certificados precisam ser utilizados exclusivamente para sua finalidade e no ambiente Pix |
| Gestão de chaves privadas | Chaves privadas não podem ser armazenadas apenas para fins históricos |
Vamos entender cada uma.
A versão 6.00 incluiu uma nova seção dedicada à lista de endereços IP autorizados a acessar a ICOM.
Os participantes devem cadastrar previamente, no módulo SPI do SPB-Web, os endereços IP que poderão realizar esse acesso. Conexões provenientes de origens não registradas devem ser bloqueadas.
Na prática, isso adiciona uma nova camada ao controle de acesso.
A autenticação por certificado continua existindo, mas deixa de ser o único fator considerado: a origem da conexão também precisa estar previamente autorizada.
Só que existe um ponto particularmente relevante para os times de Segurança e GRC: a exigência não termina na configuração da lista.
O Manual determina que o participante mantenha um processo formal de gestão dos IPs cadastrados, contemplando procedimentos de inclusão, exclusão, revisão periódica e registro das alterações.
Ou seja, não basta configurar uma allowlist e esquecê-la.
A instituição precisa conseguir administrar esse controle ao longo do tempo.
Isso envolve perguntas como:
Para esse requisito, o Banco Central definiu 23 de julho de 2026 como a data a partir da qual a alteração passou a ser exigida no ambiente de produção.
Portanto, neste momento, a discussão já não deveria estar somente em implementar o controle, mas também em garantir que ele esteja sendo gerenciado e que a instituição consiga demonstrar isso.
A segunda mudança está entre as mais relevantes da versão 6.00, principalmente pela proximidade do prazo de adequação.
O Manual determina que participantes diretos utilizem certificados digitais ICP-Brasil no padrão SPB de forma exclusiva no ambiente Pix e restritos à finalidade para a qual foram emitidos.
Em termos simples, um certificado não pode mais desempenhar funções diferentes daquelas para as quais foi criado.
O CERTPIC, utilizado para autenticação e criptografia da conexão, não pode ser utilizado para assinatura de mensagens.
Da mesma forma, o CERTPIA, destinado à assinatura digital, não pode ser utilizado para autenticação do canal.
Além disso, certificados destinados ao Pix não devem ser empregados em outros ambientes, como SPB ou MES.
A lógica por trás da mudança é reduzir o escopo de utilização de cada credencial.
Quando um mesmo certificado é utilizado para diferentes finalidades ou ambientes, um eventual comprometimento pode produzir um impacto maior.
Ao restringir cada certificado à sua função, cria-se uma segregação mais clara e diminui-se a superfície associada àquela credencial.
É um princípio conhecido em segurança: um ativo deve possuir apenas os privilégios e funções necessários para desempenhar seu papel.
As novas regras passaram a vigorar em junho, e desde então ficou vedado o envio de novos certificados que não atendam aos requisitos estabelecidos na seção 5.1.
No entanto, participantes que já utilizavam certificados em desconformidade receberam um período para adequação.
No ambiente de produção, esse prazo termina em:
6 de setembro de 2026.
Para as instituições enquadradas nesse cenário, portanto, a revisão não deve considerar apenas a validade dos certificados.
É necessário entender:
Esse é o ponto que merece maior atenção nas próximas semanas.
A terceira mudança está relacionada aos dados de auditoria e à gestão de chaves criptográficas.
O Manual estabelece que os certificados utilizados no âmbito do Pix, inclusive aqueles já desativados, e suas respectivas chaves públicas, sejam armazenados para permitir consultas históricas e validação de assinaturas digitais quando necessário.
A versão 6.00, porém, deixou explícita uma distinção importante.
Para fins históricos, o armazenamento de chaves privadas é vedado.
Essas chaves devem permanecer exclusivamente em ambientes seguros e de uso restrito às operações de geração de assinaturas e decifragem de dados.
A mudança reforça um princípio importante de segurança: preservar informação para auditoria não significa manter indefinidamente ativos sensíveis que não são necessários para aquela finalidade.
Na prática, isso exige atenção ao ciclo de vida das chaves criptográficas, às políticas de retenção e aos mecanismos utilizados pela instituição para controlar seu armazenamento e acesso.
IPs, certificados digitais e chaves criptográficas parecem assuntos essencialmente técnicos.
Mas existe uma característica comum às três mudanças:
o controle precisa ser administrado ao longo do tempo.
No caso dos IPs autorizados, não basta cadastrá-los. É necessário definir processos para inclusão, exclusão, revisão e registro.
Nos certificados, não basta verificar se eles existem e estão válidos. É necessário controlar sua finalidade e os ambientes nos quais são utilizados.
Na gestão de chaves, é preciso entender o que deve ser preservado, por quanto tempo e sob quais condições.
É nesse ponto que um requisito técnico se transforma também em uma questão de governança.
Porque implementar um controle é uma coisa.
Conseguir responder, meses depois, quem é responsável por ele, quando foi revisado, quais mudanças ocorreram e quais evidências demonstram sua execução é outra.
Com parte dos requisitos já em vigor e o prazo de setembro se aproximando para os certificados em desconformidade, quatro frentes merecem atenção.
O primeiro passo é avaliar o impacto da versão 6.00 considerando a modalidade de participação e o ambiente tecnológico da organização.
Nem toda mudança necessariamente produzirá o mesmo impacto para todos os participantes.
A instituição precisa comparar os requisitos com aquilo que já existe.
No caso dos certificados, por exemplo, é importante mapear os certificados utilizados atualmente e entender suas respectivas finalidades e ambientes.
No controle de IPs, é necessário verificar não apenas se a lista foi configurada, mas se existe um processo estabelecido para sua gestão.
Com o cenário mapeado, fica possível separar os controles já adequados daqueles que ainda precisam de ajustes.
Para participantes com certificados em desconformidade com a seção 5.1, essa revisão se torna especialmente relevante diante do prazo de 6 de setembro de 2026.
Adequação regulatória não deveria produzir somente uma fotografia daquele momento.
Depois que o controle é implementado, alguém precisa ser responsável por mantê-lo.
Isso significa conectar:
requisito > controle > responsável > evidência > revisão > plano de ação.
Sem essa estrutura, existe o risco de resolver uma pendência hoje e reencontrá-la meses depois em uma auditoria ou nova revisão regulatória.
As alterações publicadas pelo Banco Central são específicas, mas refletem uma transformação mais ampla.
Em ambientes regulados, não basta mais afirmar que determinado controle existe.
As instituições precisam conseguir demonstrar que conhecem os requisitos aos quais estão submetidas, implementaram os controles necessários, possuem responsáveis definidos e conseguem manter evidências de que esses controles continuam funcionando.
À medida que aumentam o número de sistemas, fornecedores, requisitos, auditorias e evidências, administrar essa operação de forma dispersa se torna cada vez mais complexo.
Por isso, segurança regulatória passa a depender não apenas de implementação técnica, mas também de uma estrutura contínua de Governança, Riscos e Compliance.
A hunterstack.io centraliza requisitos, controles, riscos, evidências, responsáveis e planos de ação em uma única operação de GRC, permitindo que empresas acompanhem sua evolução de segurança e compliance de forma contínua.
Em atualizações como a versão 6.00 do Manual de Segurança do SFN, o desafio não é apenas descobrir o que precisa mudar.
É saber o que já está adequado, quais gaps ainda existem, quem responde por cada ação e como comprovar que os controles continuam funcionando.
Porque, principalmente em ambientes regulados, estar adequado hoje é apenas parte do trabalho. Manter essa adequação é o verdadeiro desafio.
Saiba mais em: