Steps to reproduce the issue:
1. Use a smart card certificate accessed through a Windows CryptoAPI CSP.
2. Make sure the certificate chain is trusted (e.g. EUTL loaded).
3. Case A: set Default Signing Format to "PKCS#7 - Detached" and sign any PDF.
4. Case B: set Default Signing Format to "CAdES-Equivalent", enable "Include signature's revocation status", and sign any PDF.
5. Check the signature status immediately after signing.

Environment:
- OS: [Windows version], x64
- Acrobat Reader 64-bit 26.002.21996 (TrustedMode true) and 26.002.22031
- Signing through a third-party smart card CryptoAPI CSP (x64), provider type PROVRSAFULL
- Certificate: qualified certificate

Expected result:
Both cases produce a valid signature. Acrobat passes the correct digest to the CSP with a single CryptSetHashParam(HP_HASHVAL) and then calls CryptSignHash.

Observed result:
In both cases the signature is invalid immediately after signing.
If the EUTL lists are not loaded, signatures are created correctly.

CSP debug logs:
- CryptCreateHash, then 18 CryptSetHashParam(HP_HASHVAL) calls on the same HCRYPTHASH, each with a different value. The last value is always e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 (SHA-256 of empty input), and CryptSignHash is called on that object.
- All CSP calls return success.

Analysis of a signed PDF (Case A, PKCS#7):
- Decrypting the RSA signature value with the signer's public key gives a SHA-256 DigestInfo containing e3b0c442...7852b855 (empty input). EU DSS reports SignatureIntact = false.
- The correct document does not appear among the 18 HP_HASHVAL values in the CSP log. Acrobat never passed the document digest to the CSP.

CSP debug logs, the EU DSS diagnostic data and a sample signed PDF are available privately on request.
If you need any additional logs or tests, we will be happy to help.