Official documentation checked October 14, 2026.
If a certificate or PFX password prompt repeats while you open Copilot or a Microsoft 365 document, stop before deleting certificates. The timing does not prove that Copilot has corrupted a certificate. The dialog might belong to certificate import, organizational sign-in, email encryption or another component involved in opening the app.
Removing the wrong certificate or private key can break authentication or access to encrypted content. Disabling automatic enrollment or deleting trusted root certificates is not an appropriate general Copilot repair.
Identify the exact prompt before entering credentials
Record the dialog title, exact wording, application, time and the action that triggered it. Determine whether it asks for a PFX file password, a smart-card PIN, certificate selection or ordinary Microsoft account sign-in. These are different operations.
A PFX file can contain certificates and private keys. Its import password protects that file; it is not automatically your Microsoft 365 password. Microsoft’s Import-PfxCertificate documentation distinguishes the password from whether the imported private key is exportable.
- If you deliberately started an approved certificate import, use the certificate issuer’s instructions and obtain the password through an approved channel.
- If you did not start an import, cancel the unexpected prompt and ask IT which component requested it.
- If the prompt is for organizational certificate sign-in, do not repeatedly guess a PFX password or smart-card PIN.
Do not upload a PFX file, private key, password or PIN to Copilot, a forum or an ordinary support attachment. A cropped screenshot of the dialog can help IT, but check it for sensitive account details first.
Narrow down sign-in versus document or email access
Save your work, close the affected application normally and note whether the prompt returns during sign-in, when opening one particular file, or only when accessing an encrypted message. Compare with a non-sensitive test document. This isolates the trigger without changing security settings.
If your organization uses Microsoft Entra certificate-based authentication, the browser can reuse a previously selected certificate. Microsoft recommends closing the browser session and opening a new one before retrying after a CBA failure. Choose the certificate approved by your organization, or use another sign-in method only if the organization offers and permits it. See the CBA troubleshooting FAQ.
An administrator can then correlate the failure with Entra sign-in logs. Certificate-based authentication is a distinct organizational authentication method; a failed attempt does not establish that certificates should be removed.
For Outlook-only symptoms, check whether S/MIME is involved. The relevant settings are Settings > Mail > S/MIME in new Outlook, and File > Options > Trust Center > Trust Center Settings > Email Security in classic Outlook. Review the configured identity with IT using Microsoft’s S/MIME setup guide. Do not turn off required encryption to make the prompt disappear.
Have the certificate owner perform any necessary repair
Provide IT with the trigger, application version, affected account, error time and any certificate subject, issuer or thumbprint visible in the approved diagnostic view. Ask them to identify the certificate’s purpose and whether its private key is needed for existing encrypted data before removing or replacing anything.
Appropriate repair may involve correcting enrollment, certificate selection, trust or application configuration—but only after the cause is established. Microsoft’s certificate-store management guidance emphasizes verifying the owner and destination and avoiding exportable private keys without an approved need.
Leaving an import password blank does not bypass a password-protected PFX. Marking a key exportable is not a fix for repeated prompting. If you already deleted a certificate following earlier advice, tell IT exactly which store and certificate were affected; avoid further cleanup while recovery options are assessed.
Retest the original sign-in and protected-content workflow after the approved repair. Successful access with the intended protection still in place—not merely the absence of a dialog—is the correct completion check.