Featured
- Get link
- X
- Other Apps
Restrict maximum certificate lifetime - limitação do tempo máximo de validade de certificados e client secrets
A política de Restrição de vida de Certificados faz parte do Microsoft Entra ID Conditional Access Authentication Strength policies, e tem como objetivo limitar o tempo máximo de validade de certificados e client secrets usados por aplicativos registrados no Entra ID (App registrations).
Ela não afeta usuários humanos, sendo voltada apenas para identidades não humanas (service principals / aplicações) - ou seja, aquilo que autentica via API, como o Zabbix, scripts PowerShell automatizados, integrações de monitoramento, etc.
Historicamente, os client secrets e certificados podiam ter validade muito longa — até 2 anos, 5 anos ou “sem expiração”, o que gerava risco de segurança, já que secrets antigos podiam vazar e continuar válidos por muito tempo, certificados expiravam sem controle e quebravam integrações críticas e não havia uma padronização para renovação segura.
Com essa política, o Entra ID impõe limites máximos de validade e, em alguns casos, bloqueia completamente secrets longos, forçando o uso de certificados curtos e práticas modernas (Managed Identities, Federated Credentials, etc).
Como ela funciona na prática
Quando você ativa Restrict maximum certificate lifetime, o Entra ID passa a aplicar regras automáticas na criação de novos certificados (e em alguns casos, também de client secrets).
A política define o tempo máximo permitido para validade desses certificados — por exemplo, 180 dias.
Significa que:
-
Quando alguém tentar adicionar um novo certificado em um App Registration, o portal ou API não aceitará certificados com validade maior que o limite definido.
-
Se o certificado enviado tiver validade maior, a criação falhará.
-
Se você gerar o certificado dentro do limite, ele será aceito normalmente.
Essa política não encurta certificados já existentes, apenas controla a criação dos novos.
Ativação do método X509Certificate
A ativação é segura desde que seu ambiente use apenas certificados controlados, mas pode gerar rupturas se você tiver apps que criam certificados automaticamente (autoregistrados) ou se a validade padrão dos certificados for maior que o limite que você definir.
Cuidados a serem tomados
X509Certificate (Certificate-Based Authentication) no Microsoft Entra ID, o mesmo passa a considerar o certificado como método válido e prioritário de autenticação (MFA).Isso faz com que o Entra comece a exigir que qualquer autenticação — web, PowerShell, CLI, portal, apps — passe pela verificação de certificado.
Ou seja:
-
Ele não desativa o authenticator, mas adiciona a exigência de certificado como camada obrigatória (dependendo da configuração);
-
Isso simula um cenário de CBA corporativo, usado em empresas que emitem certificados a todos os usuários via CA interna (ex: login com smartcard).
O resultado é que todos os usuários passam a receber prompt pedindo um certificado válido emitido por uma CA confiável — e quem não tem, não consegue mais autenticar.
O Entra ID entende que, ao ativar o método X509Certificate, o administrador deseja que a autenticação por certificado seja uma opção corporativa válida.
Se não houver escopo definido (grupos ou usuários específicos), ele aplica a configuração globalmente.
Na prática:
-
A política entra no modo "Enabled for all users";
-
Todos os endpoints de autenticação (como login.microsoftonline.com, portal.azure.com, PowerShell e MS Graph) passam a exigir a verificação de certificad
Quando você ativa a configuração de controle de validade de certificados ou o método de autenticação por certificado (CBA/X509Certificate) no Microsoft Entra ID, é possível segmentar quem será afetado, via grupos.
Essa segmentação torna-se o método mais seguro de aplicar o X509Certificate, mantendo o controle de validade de certificados (para apps e APIs). O grupo que você vincula à configuração
X509Certificate serve para definir o escopo de quem será impactado pela exigência de certificados, ou seja, somente os membros desse grupo serão obrigados a se autenticar via certificado e todos os usuários fora do grupo continuam logando normalmente com MFA, Authenticator, senha, etc.- Crie um grupo de Segurança no Entra, do tipo atribuição (SG_Certificate_BasedAuth) e adicione apenas Service Principals (Enterprise Apps) que usam certificados para autenticação
- Associe o grupo à política
Ou via Portal do Entra ID
Entra ID > Authentication methods > Policies > Certificated-based authentication
Habilite a política e adicione o grupo alvo:
A inclusão dos Enterprise Apps no grupo de Segurança do Entra pode ser feita por Powershell, usando o seguinte script: powershell_scripts/Microsoft/365/Implementations/CertficateAuthBasedLifetime/adding_EnterpriseApps.ps1 at main · iamjrbro/powershell_scripts
Para listar os apps em seu tenant: powershell_scripts/Microsoft/365/Implementations/CertficateAuthBasedLifetime/list_AppRegistration.ps1 at main · iamjrbro/powershell_scripts
Aplicações com particularidades
Aplicações como Power Virtual Agents (Customer Service Copilot Bot), Microsoft Graph connectors e integrações do Power Platform costumam se auto-registrar com certificados válidos por 1 ano.
Se o limite estiver, por exemplo, em 90 dias, esses apps não conseguirão concluir o registro e falharão na autenticação inicial.
Impacto: o app não sobe ou perde conexão com o tenant até o administrador ajustar a política ou recriar o certificado manualmente com validade menor.
Se a integração usa client secret, não há impacto.
Mas se ela usa client certificate, o certificado precisa respeitar o limite definido.
Caso contrário, ao tentar renovar o certificado ou registrar um novo, o Entra ID rejeitará a operação.
Impacto: a automação ou leitura via API pode parar de funcionar até que um novo certificado dentro do limite seja emitido.
Se você usa uma CA interna para emitir certificados (por exemplo, em ambientes híbridos com ADFS ou Intune), será necessário ajustar o template de emissão para que a validade máxima respeite o limite configurado no Entra ID.
Alguns apps nativos da Microsoft (como Exchange Online, Teams, SharePoint, Intune e Azure DevOps) usam certificados internos gerenciados pela própria Microsoft, que não são afetados por essa política. Ela se aplica apenas aos objetos registrados no seu tenant.
Onde configurar a política
Você a encontra em:
Microsoft Entra admin center → Identity → Protection → Authentication strengths → Certificate lifetime restriction (preview)
ou, em algumas versões, em:
Microsoft Entra admin center → Identity → Applications → App registrations → Policies → Restrict maximum certificate lifetime
A interface pode mudar conforme o tenant, pois o recurso ainda está sendo implementado em preview.
- Defina o tempo máximo de validade das Secrets
- Selecione o escopo de aplicação (se será aplicado à todas aplicações, algumas aplicações com exclusão ou somente àquelas aplicações selecionadas)
O que exatamente ela restringe
Ela impõe um limite máximo de dias que um certificado pode ter de validade.
Os valores comuns são:
-
90 dias (padrão mais seguro)
-
180 dias (equilíbrio entre segurança e praticidade)
-
365 dias (casos de exceção)
Por exemplo:
Se o limite for 180 dias e você tentar registrar um certificado de 1 ano (365 dias), o Entra ID rejeita com erro dizendo que o certificado excede o tempo máximo permitido.
O que acontece com certificados e secrets existentes
Essa política não tem efeito retroativo. Ou seja:
-
Certificados e client secrets criados antes da política continuam válidos até a data original de expiração.
-
Quando eles expirarem e você tentar renová-los, o novo limite será aplicado.
Portanto, nenhuma integração quebra imediatamente após a ativação da política, o impacto só ocorre no próximo ciclo de renovação.
Como adicionar exceções (exclusion list)
A Microsoft entende que há casos em que certos apps precisam de certificados com validade maior — por exemplo, integrações críticas, aplicações legadas ou monitoramentos.
Por isso, a política permite excluir aplicativos específicos do limite, tanto durante sua configuração, quanto posteriormente.
-
Acesse o portal Microsoft Entra admin center
-
Vá em Identity → Applications → Enterprise applications → Certificate lifetime restrictions (preview) ou Microsoft Entra admin center → Identity → Applications → App registrations → Policies → Restrict maximum certificate lifetime
-
Encontre a política ativa “Restrict maximum certificate lifetime”
-
Selecione Excluded Apps (ou “Assignments → Exclude”)
-
Clique em Add applications
-
Selecione os apps que você quer excluir
-
Salve
Esses aplicativos não serão afetados pelo limite de validade — eles poderão continuar criando certificados e secrets conforme as regras antigas (até 2 anos ou mais).
Como verificar se o app é “Microsoft-managed” é imune à política
No portal Entra ID:
- Vá em Identity → Applications → Enterprise Applications ou Entra ID → App Registration
- Selecione o app (ex: “Customer Service Copilot Bot”).
- Vá em Branding & Properties
- Verifique se o campo Publisher mostra algo como “Microsoft Applications”, “Microsoft Corporation”.
Se for esse o caso, trata-se de um app gerenciado pela Microsoft, e ele não é afetado pela política, não precisa ser incluído na lista de exclusões, e não corre risco de quebrar por causa do limite de certificado.
E se o app for um Copilot customizado (criado por você)?
Se você criou um Copilot personalizado via Power Virtual Agents e ele gerou um App Registration em nome do seu tenant, então o app é considerado “tenant-managed” e a política se aplica normalmente. Nesse caso, se ele usar um certificado acima do limite, o Entra ID bloqueará a criação. Você pode, entretanto, adicionar esse app na lista de exclusões da política para evitar bloqueios.
Me acompanhe em outras redes sociais: iamjuliaribeiro | Instagram, Twitch | Linktree
- Get link
- X
- Other Apps
Popular Posts
Fim do salvamento local no Office 365 e a migração para a nuvem
- Get link
- X
- Other Apps
Automatizando a Sincronização do SharePoint no Windows com Microsoft Intune
- Get link
- X
- Other Apps








Comments
Post a Comment