Share via

KB5082198: PowerShell cannot access certificate private keys after April 2026 Windows Server update until certificates are re-imported

Stefan Bretschneider 0 Reputation points
2026-06-01T10:38:00.84+00:00

After installing the April 2026 cumulative update KB5082198 on Windows Server 2016, we observed problems accessing private keys of certificates from PowerShell.

Environment:

  • OS: Microsoft Windows Server 2016
  • Update: KB5082198, OS Build 14393.9060
  • PowerShell: Windows PowerShell 7.x
  • Certificate store: LocalMachine\My
  • Certificate source/type: PFX / AD CS

Observed behavior:

  • The certificates were still visible in the Windows certificate store.
  • PowerShell scripts that previously worked could no longer access or use the private key.
  • Re-importing the affected certificates fixed the issue.
  • No application/script changes were made before the failure.
  • The issue appeared after installing KB5082198.

Expected behavior:

Existing certificates with private keys should remain usable from PowerShell after the cumulative update.

Workaround:

Export/re-import of the affected certificates restored private-key access.

Question:

Is this a known compatibility issue with KB5082198 or with the related Windows cryptographic provider changes around CVE-2024-30098 / KB5073121?

This looks potentially related to the Microsoft guidance for smart card propagated certificates and CSP/CAPI vs KSP/CNG handling:

https://support.microsoft.com/topic/guidance-for-certificate-handling-for-smart-card-propagated-certificates-792002ef-4c98-4736-9393-0622debe2989

However, the KB5082198 known issues page does not currently list a private-key or PowerShell certificate access issue:

https://support.microsoft.com/topic/april-14-2026-kb5082198-os-build-14393-9060-9c1c628a-9294-4ac3-bbf0-05bbba21a6ef

Can Microsoft confirm whether this is expected behavior, a known issue, or whether additional diagnostics should be collected?

Windows for business | Windows Server | User experience | PowerShell
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jason Nguyen Tran 18,725 Reputation points Independent Advisor
    2026-06-01T11:21:26.9+00:00

    Hello Stefan Bretschneider,

    After the April 2026 cumulative update KB5082198, some environments have reported issues where PowerShell scripts cannot access certificate private keys until the certificates are re‑imported. This behavior is linked to changes in cryptographic provider handling introduced around CVE‑2024‑30098 and KB5073121, which tightened how CSP/CAPI and KSP/CNG providers interact with stored certificates.

    The driver behind this is that certain certificates imported under older provider contexts may not expose their private keys correctly after the update. Re‑importing the PFX re‑binds the certificate to the updated provider stack, which explains why your workaround is effective.

    For diagnostics, you can enable CAPI2 logging in Event Viewer to capture detailed certificate access traces, which will help confirm whether the provider mismatch is the root cause. If you rely on automated scripts, re‑importing certificates proactively or updating them through AD CS with the latest provider settings may prevent recurrence.

    I hope the response provided some helpful insight. If you find this answer useful, please hit “accept answer” so I know it addressed your concern.

    Jason.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments

  2. AI answer

    2026-06-01T10:38:36.4333333+00:00

    The described behavior is consistent with the broader cryptographic changes introduced to address CVE-2024-30098, but there is no documentation in the provided context that explicitly lists KB5082198 or a PowerShell-specific private-key access issue as a known problem.

    From the available information:

    • Windows updates released starting October 2025 introduce stricter requirements that RSA-based smart card certificates use Key Storage Provider (KSP) instead of Cryptographic Service Provider (CSP). This affects how private keys are retrieved and used, especially when applications rely on legacy CAPI/CSP behavior.
    • The guidance for smart card propagated certificates explicitly states that developers must update applications to use Key Storage Retrieval via the CNG Key Storage API and to call CryptAcquireCertificatePrivateKey with CRYPT_ACQUIRE_PREFER_NCRYPT_KEY_FLAG, then select the correct API set (CAPI vs CNG) based on pdwKeySpec.
    • For affected platforms (Windows 10/11, Windows Server 2016/2019/2022/2025), Microsoft documents that:
      • Smart card authentication and certificate operations can fail after the security updates that enforce KSP over CSP.
      • Common symptoms include failures in applications relying on certificate-based authentication and errors around CryptAcquireCertificatePrivateKey.
      • A temporary registry-based workaround (DisableCapiOverrideForRSA under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais) can switch behavior from Enforcement to Audit mode, but this workaround is scheduled to be removed (planned April 2026 for many SKUs, and support for the registry key removed by February 2027 per the guidance).

    Given this, the scenario described (existing certificates visible in the store, but private keys no longer accessible from PowerShell until re-imported) aligns with the enforcement of the new cryptographic behavior rather than a separate, documented “bug” in KB5082198:

    • The enforcement around RSA smart card / CSP usage can change how existing keys are exposed or retrieved.
    • Applications and scripts that implicitly relied on CAPI/CSP behavior may fail once enforcement is active, even though the certificates remain present in the store.
    • Re-importing certificates can cause them to be stored or bound in a way that is compatible with the new KSP/CNG expectations, restoring private-key access.

    However, the provided context does not:

    • Explicitly list KB5082198 as having a known issue where PowerShell cannot access private keys.
    • Explicitly confirm a PowerShell-specific regression or a known compatibility issue tied to that particular KB.

    What is documented and can be confirmed from the context:

    1. There is a broad, known change in Windows cryptographic behavior tied to CVE-2024-30098 that:
      • Requires RSA-based smart card certificates to use KSP instead of CSP.
      • Can cause failures in certificate-based operations when applications continue to use CAPI/CSP paths.
      • Provides a temporary registry-based workaround (DisableCapiOverrideForRSA) that will be removed in updates planned for April 2026 and fully unsupported by February 2027.
    2. Microsoft’s guidance for a permanent resolution is:
      • Update authenticating applications to perform key storage retrieval using the CNG Key Storage API as documented in “Key Storage and Retrieval”.
      • Use CryptAcquireCertificatePrivateKey with CRYPT_ACQUIRE_PREFER_NCRYPT_KEY_FLAG and select CAPI vs CNG based on pdwKeySpec (CAPI for AT_KEYEXCHANGE/AT_SIGNATURE, CNG for CERT_NCRYPT_KEY_SPEC).
    3. For environments encountering failures after the security updates:
      • Microsoft documents that setting DisableCapiOverrideForRSA to 0 (or removing the key) switches from Enforcement to Audit mode, temporarily restoring behavior, but this is explicitly temporary and scheduled for removal.

    Based on the context, the most accurate classification is:

    • The behavior is consistent with the expected impact of the CVE-2024-30098-related cryptographic enforcement.
    • It is not documented here as a separate, KB5082198-specific known issue.
    • For definitive confirmation and deeper diagnostics (e.g., to verify whether this is a product bug vs expected enforcement side effect), Microsoft Support should be engaged, especially if:
      • PowerShell 7.x is using standard .NET/X509 APIs and still cannot access keys that should be KSP-backed.
      • The issue persists even after verifying key storage provider type and after re-importing certificates.

    In addition to the export/re-import workaround already identified, diagnostics that would typically be relevant (per the documented guidance) include:

    • Checking whether the affected certificates are using CSP vs KSP and whether they are RSA-based smart card or PFX-based keys.
    • Verifying whether the DisableCapiOverrideForRSA registry value is present and its value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais.
    • Reviewing system logs for Smart Card Service or Microsoft-Windows-Smartcard-Server Event ID 624 indicating use of CAPI for RSA operations.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.