Yes. One code signing certificate works for 32-bit executables, 64-bit executables, and ARM64 executables. The same signtool command, the same certificate, and the same thumbprint apply to all three without any changes.
The rest of this article explains why, covers the scenarios where you might expect it to be more complicated (multi-architecture installers, kernel drivers, ARM builds), and describes the one genuine exception where architecture does affect how you sign.
Why the Same Certificate Works for Both
A code signing certificate contains two things that matter for signing: your organization’s verified identity and a cryptographic public key. Neither is architecture-specific. The certificate has no concept of CPU architecture. It doesn’t know whether you’re signing a 32-bit DLL or a 64-bit installer.
Authenticode signing works at the PE (Portable Executable) file format level. Both 32-bit and 64-bit Windows executables use PE format : the format has a flag that indicates whether the binary targets x86 or x64, but the signature mechanism is identical for both. signtool computes a SHA-256 hash of the file’s content, signs that hash with your private key, and embeds the signature in the file’s certificate table. The process is the same regardless of what the PE flag says about architecture.
When Windows verifies the signature at execution time, it performs the same chain verification regardless of whether it’s running a 32-bit or 64-bit binary. The code integrity system verifies the embedded signature against the certificate chain. Architecture is not part of that verification.
The Command Is Identical for Both Architectures
This is the practical confirmation. Signing a 32-bit executable and signing a 64-bit executable uses exactly the same signtool command:
| # Sign a 32-bit executable:
signtool sign /a /fd sha256 /tr http://timestamp.digicert.com /td sha256 /v MyApp_x86.exe
# Sign a 64-bit executable: signtool sign /a /fd sha256 /tr http://timestamp.digicert.com /td sha256 /v MyApp_x64.exe
# Sign both in a single command: signtool sign /a /fd sha256 /tr http://timestamp.digicert.com /td sha256 /v MyApp_x86.exe MyApp_x64.exe
# Or sign an entire directory of mixed-architecture files: signtool sign /a /fd sha256 /tr http://timestamp.digicert.com /td sha256 /v .\release\*.exe .\release\*.dll |
Signing all architecture variants in a single signtool invocation is more efficient than one call per file. It uses a single token PIN prompt (if using a hardware token), contacts the timestamp server once, and is faster overall. signtool accepts multiple filenames or wildcards and processes them all with the same certificate.
ARM64 Executables: Also Covered by the Same Certificate
ARM64 Windows executables are PE format files just like x86 and x64 binaries. signtool signs them with the same command and the same certificate. Windows on ARM verifies ARM64 binary signatures using the same Authenticode mechanism as x64 Windows.
The ARM64 question became more relevant when Windows 11 on ARM (Qualcomm Snapdragon-powered laptops and Microsoft’s own Copilot+ devices) went mainstream. If your application ships an ARM64-native binary for performance on these devices, no separate certificate or signing process is needed. Add the ARM64 binary to your existing signing step.
ARM64EC (ARM64 Emulation Compatible) binaries, used to interoperate with x64 code in mixed-architecture scenarios, are also PE format and signed the same way.
32-bit Apps Running on 64-bit Windows (WoW64)
When a signed 32-bit executable runs on 64-bit Windows under WoW64 (Windows 32-bit on Windows 64-bit), the signature verification is performed on the 32-bit binary at load time. The verification uses the same Authenticode mechanism as 64-bit binary verification. The signature on the 32-bit binary is verified against your certificate, which is in the system’s trusted certificate store. Architecture has no effect on this process.
There is no need to re-sign a 32-bit binary with a different certificate when you want it to run on 64-bit Windows. The original signature on the 32-bit binary remains valid.
Multi-Architecture Installers and Packages
Many publishers ship one installer that selects and installs the appropriate architecture at runtime. Signing this correctly involves two levels:
The installer itself
The installer executable (whether a 32-bit or 64-bit binary) is signed as a single file. Users see this signature when they run the installer and the UAC dialog appears. Sign the installer with your certificate using the standard signtool command.
The embedded payloads
If your installer embeds both the x86 and x64 versions of your application and extracts the appropriate one at install time, each embedded binary should also be individually signed before it is packaged into the installer. Signing the installer doesn’t sign the files inside it; those files need independent signatures for Windows to trust them after extraction.
The workflow: sign each architecture-specific binary first, then package them into the installer, then sign the installer itself. The installer’s signature covers the entire installer binary including the embedded payload files. The individual payload signatures cover those specific binaries when they are extracted and run.
MSIX and MSIXBUNDLE
MSIX packages can target specific architectures. An MSIXBUNDLE aggregates architecture-specific MSIX packages into a single distributable. The bundle itself is signed, but each architecture-specific package within it should also be signed. signtool signs MSIX and MSIXBUNDLE files with the same command as executables, with the additional requirement that the certificate Subject must exactly match the Publisher attribute in the appxmanifest.
The One Real Exception: Kernel-Mode Drivers
For user-mode applications, DLLs, services, installers, scripts, and packages, one certificate signs everything regardless of architecture. Kernel-mode drivers have stricter and architecture-specific requirements.
| Driver type | Signing requirement | Architecture matters? |
| 64-bit kernel-mode drivers (.sys) for Windows 10/11 | Must be submitted to and cross-signed by Microsoft’s Hardware Dev Center (HDC). Requires an EV code signing certificate for the HDC submission. Self-signed or standard OV-signed 64-bit drivers will not load on production systems with Secure Boot enabled. | Yes: 64-bit kernel drivers have strict HDC requirements that 32-bit drivers did not require in older Windows versions. |
| 32-bit kernel-mode drivers | Also require proper signing for modern Windows; the same HDC process applies. Pure 32-bit Windows is increasingly rare. | Architecture-specific rules are less of a distinction here; modern Windows enforces signature requirements on all kernel drivers. |
| User-mode drivers (UMDF) | Treated as standard executables. Same OV certificate, same signtool command. | No: standard Authenticode applies. |
If you are building a kernel-mode driver and wondering about the 32-bit vs 64-bit signing distinction, the relevant question is not about your OV certificate at all. Kernel-mode drivers on 64-bit Windows require Microsoft cross-signing through HDC, which requires a separate EV code signing certificate for the submission process. The certificate you use for your regular application binaries does not provide the attestation signing that kernel drivers need.
What About Other Platforms?
The 32-bit vs 64-bit question has answers on other platforms too, since some developers ship cross-platform software:
- macOS: Apple Developer ID certificates work for both x86_64 and ARM64 (Apple Silicon) macOS binaries. Universal binaries (fat binaries containing both architectures) are signed as a single unit with codesign, which handles both architecture slices. One Developer ID certificate covers all macOS architectures.
- Android: APK signing is architecture-agnostic at the APK level. An APK may contain native libraries for multiple ABIs (armeabi-v7a, arm64-v8a, x86, x86_64), and the APK is signed as a whole. The same signing key and jarsigner/apksigner command covers all ABIs within the package.
- Linux: Linux executables use ELF format rather than PE. Standard Authenticode code signing (signtool) does not apply to ELF binaries. Linux package signing uses distribution-specific mechanisms (GPG-signed packages for apt/rpm) rather than embedded Authenticode signatures.
Frequently Asked Questions
Do I need a separate certificate for each architecture?
No. One certificate signs all architectures. The certificate represents your organization’s identity, not the architecture of what you’re signing. The same certificate that signs your x64 installer also signs your x86 installer, your ARM64 DLLs, and your MSIX packages.
Does Windows check the architecture when verifying a signature?
No. Windows Authenticode verification checks the certificate chain, the signature hash, and revocation status. It does not check CPU architecture. A valid signature on a 32-bit binary is verified the same way as a valid signature on a 64-bit binary. The signature is either valid (cryptographic hash matches, chain verifies) or it is not, regardless of architecture.
My build produces both x86 and x64 versions. Do I sign them as part of the same step?
You can, and it is more efficient to do so. signtool accepts multiple files in a single command, signing all of them with the same certificate. If you are signing from a hardware token, one PIN entry covers all files in the batch. If you are signing in a CI/CD pipeline with a cloud HSM service, batching reduces the number of API calls. The result is identical to signing each file separately, but faster.
Does the architecture of the machine I’m signing on matter?
No. You can sign a 64-bit executable from a 32-bit process running signtool, or a 32-bit executable from a 64-bit machine. signtool reads the PE file, computes the signature, and embeds it. The architecture of the machine running signtool is irrelevant to the architecture of the binary being signed. The Windows SDK includes both 32-bit and 64-bit versions of signtool, and either signs binaries of any architecture.
Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.
Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.