Code signing looks optional until it isn't. A missing or untrusted signature triggers SmartScreen warnings, blocks execution on hardened endpoints, and fails compliance checks in regulated environments. In healthcare, fintech, and government shops, that is not a recoverable situation mid-rollout.
This guide covers the full workflow: what code signing actually does to an MSI, which certificate type you need, how to sign with signtool.exe, how Intune validates the signature, and where the process breaks down in practice.
Why Code Signing an MSI Matters for Intune Deployments
Intune deploys Win32 apps as .intunewin packages, but the MSI or EXE inside that wrapper still runs on the endpoint under the SYSTEM context. Windows evaluates the Authenticode signature on that inner file before execution.
Without a valid signature from a trusted CA, you get one of three outcomes:
- SmartScreen blocks the install — silently or with a prompt, depending on endpoint policy.
- AppLocker or WDAC rules reject the binary — if your organization enforces publisher-based allow-listing.
- Audit logs flag the install — unsigned software creates compliance noise in regulated environments.
A valid code signature also gives you a stable publisher identity for WDAC policies. If you are building allow-lists based on publisher name rather than file hash, signing is not optional. It is the foundation.
Certificate Types: What You Actually Need
Not every certificate works for MSI signing. Get this wrong and you will produce a signature that validates locally but fails in production.
Standard Code Signing Certificate (OV or EV)
Organization Validation (OV) certificates are issued to a legal entity after identity verification. They are the baseline for internal tooling and LOB app deployment, and Windows trusts them out of the box if the CA chain is in the trusted root store.
Extended Validation (EV) certificates require stricter identity checks and are stored on an HSM or USB token. EV certs build SmartScreen reputation faster because Microsoft's SmartScreen reputation system weights them more heavily for new software.
For internal Intune deployments to company-managed endpoints, an OV certificate from a commercial CA — DigiCert, Sectigo, GlobalSign — is sufficient. For anything distributed externally or subject to SmartScreen scrutiny, use EV.
Gotcha: Self-signed certificates do not work for production Intune deployments unless you push the signing certificate to the Trusted Publishers store on every endpoint via policy. That is extra work and creates a maintenance burden. Use a commercial CA.
Internal PKI (ADCS)
If your organization runs Active Directory Certificate Services, you can sign MSIs with an internally issued code signing certificate. Domain-joined endpoints trust the internal CA chain automatically.
This works well for LOB apps deployed only to domain-joined or Intune-enrolled endpoints. It does not work if the endpoint is Azure AD-joined only and the internal CA root is not in the device's trusted root store.
Always verify the CA chain is present on the target endpoint before relying on an ADCS-issued signature.
The Signing Workflow: signtool.exe Step by Step
signtool.exe ships with the Windows SDK and Visual Studio. You need it on the machine where you are signing.
Basic Signing Command
signtool sign ^
/fd SHA256 ^
/tr http://timestamp.digicert.com ^
/td SHA256 ^
/f "C:\Certs\YourCodeSigningCert.pfx" ^
/p "YourCertPassword" ^
"C:\Packages\YourApp.msi"Flag breakdown:
/fd SHA256— file digest algorithm; use SHA256, never SHA1 in 2026./tr— timestamp server URL; always timestamp, explained below./td SHA256— timestamp digest algorithm; must match/fd./f— path to your.pfxfile./p—.pfxpassword; for HSM-based certs, use/cspand/kcinstead.
Verify the Signature
signtool verify /pa /v "C:\Packages\YourApp.msi"Output should show Successfully verified. If you see The file is not signed or A certificate chain could not be built to a trusted root authority, fix the chain before packaging for Intune.
Why Timestamping Is Non-Negotiable
A timestamp from a trusted Time Stamp Authority (TSA) embeds a cryptographic record of when the file was signed. Without it, the signature becomes invalid the moment your certificate expires. With it, the signature remains valid indefinitely — as long as it was valid at signing time.
Every MSI you deploy through Intune should be timestamped. No exceptions.
Dual Signing: SHA1 and SHA256
In 2026, if your endpoint fleet is 100% Windows 10 or later, you only need SHA256. If you are still supporting Windows 8.1 endpoints — unlikely, but it happens in legacy environments — dual-sign:
signtool sign /fd SHA1 /t http://timestamp.digicert.com /f cert.pfx /p pass app.msi
signtool sign /as /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /f cert.pfx /p pass app.msiThe /as flag appends the second signature without replacing the first.
Packaging the Signed MSI for Intune
Signing must happen before wrapping. The .intunewin container is a compressed archive. If you sign after wrapping, you are signing the container — not the MSI inside it. Intune extracts the inner file before execution, and that inner MSI is what Windows validates.
Order of operations:
- Build or obtain the MSI.
- Sign the MSI with
signtool.exe. - Verify the signature.
- Wrap the signed MSI into
.intunewin. - Upload to Intune.
Gotcha: If you re-sign an MSI that was already wrapped, you are signing the .intunewin file, not the MSI. That does nothing useful. Always sign before wrapping.
For context on when to use MSI versus .intunewin as your deployment format, the intunewin vs MSI breakdown covers the decision criteria in detail.
Detection Rules After Signing
Signing does not change the MSI's ProductCode or file paths. The most reliable detection methods remain file version or registry key — not publisher identity.
Standard registry detection for an MSI install:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{YOUR-PRODUCT-CODE}
Value: DisplayVersion
Operator: Equals
Value: 1.0.0If you are writing WDAC publisher-based rules, the signing certificate's Subject CN becomes the publisher identity. Document it. You will need it when building allow-lists.
For a full walkthrough of Intune detection rule configuration, the Intune deployment best practices guide covers the common failure modes.
Where the Manual Workflow Breaks Down
The signing workflow above assumes you already have a clean, well-formed MSI. Most of the time, you do not. You have an EXE.
Legacy software vendors ship EXEs — Inno Setup, NSIS, InstallShield wrappers around the actual installer files. You cannot sign an EXE and deploy it as an MSI through Intune. You need an actual MSI with a valid ProductCode, component structure, and uninstall string.
Repackaging an EXE into an MSI manually means capturing a VM snapshot, running the installer, diffing the system state, and authoring the MSI by hand. That process takes hours and is fragile. Capture is sensitive to system state, pre-installed software, and timing.
This is where InstallMage fits into the workflow. You upload the EXE, the AI engine identifies the installer framework, extracts the correct silent install arguments, and compiles a WiX-based MSI wrapper in an isolated container. The output is a properly structured MSI with a ProductCode, uninstall string, and ready-to-paste Intune detection rule GUIDs. The whole process takes under 3 minutes.
On the Pro tier, you supply your own .pfx file and InstallMage applies your code signature to the MSI wrapper during the build step. You get a signed, Intune-ready MSI without touching signtool.exe manually. Your certificate stays under your control — InstallMage processes the EXE in an ephemeral, stateless container and deletes it immediately after conversion.
If you are converting EXEs at scale and want to understand the full conversion pipeline before signing, the EXE to MSI guide walks through what the repackaging process actually produces.
Code Signing in Regulated Environments
In healthcare and fintech environments, code signing intersects directly with software inventory and compliance reporting. A signed MSI with a known publisher identity makes it significantly easier to build accurate software inventories — the publisher field in Add/Remove Programs is populated from the certificate.
Unsigned or self-signed packages produce inconsistent publisher strings, which creates noise in compliance dashboards and complicates audit responses.
If your organization tracks software inventory post-deployment, consistent publisher identity from a commercial CA certificate is worth the overhead. An OV certificate runs $200 to $500 per year. That is small relative to the audit risk.
Common Errors and What They Mean
| Error | Cause | Fix |
|---|---|---|
The file is not signed | signtool ran but failed silently | Check exit code; re-run with /v for verbose output |
A certificate chain could not be built | Intermediate CA cert missing | Install intermediate cert on signing machine |
| Timestamp signature could not be verified | TSA URL unreachable during signing | Check network access; retry with alternate TSA |
SignerSign() failed | PFX password wrong or cert expired | Verify password; check cert expiry date |
| SmartScreen blocks on endpoint | Certificate lacks SmartScreen reputation | Switch to EV cert or push CA to Trusted Publishers via policy |
FAQs
Do I need to code sign an MSI to deploy it through Intune?
Technically no — Intune will deploy an unsigned MSI. But on endpoints with AppLocker, WDAC, or strict SmartScreen policies, an unsigned MSI will be blocked or flagged. In regulated industries, unsigned software also creates compliance audit exposure. Sign everything you deploy.
Can I use a self-signed certificate for Intune MSI deployments?
You can, but only if you push the self-signed certificate to the Trusted Publishers store on every target endpoint via Intune policy. That adds maintenance overhead and breaks if the cert expires or is rotated. A commercial OV certificate is simpler and more reliable.
What happens if I sign the .intunewin file instead of the MSI inside it?
Nothing useful. Intune extracts the inner file before execution, and Windows validates the signature on that inner file. Always sign the MSI before wrapping it into .intunewin.
Does code signing change the MSI's ProductCode or detection rule GUIDs?
No. Signing adds an Authenticode signature to the file but does not modify the MSI database, ProductCode, or any installer properties. Your detection rules remain valid after signing.
What is the difference between an OV and EV code signing certificate for Intune use?
For internal Intune deployments to managed endpoints, OV is sufficient. EV certificates carry more weight with Microsoft SmartScreen's reputation system — that matters for externally distributed software. EV certs also require an HSM or hardware token, which adds a step to the signing workflow.
How do I timestamp an MSI signature and why does it matter?
Pass the /tr flag with a TSA URL to signtool.exe during signing. Without a timestamp, the signature becomes invalid when the certificate expires. With one, the signature stays valid indefinitely as long as it was valid at the time of signing. Always timestamp.
Can InstallMage apply my code signing certificate automatically during conversion?
Yes. On the Pro tier, you upload your .pfx file and InstallMage applies your certificate to the WiX-based MSI wrapper during the build step. The signed MSI is included in the download output. Your .pfx is processed in an ephemeral container and deleted immediately after conversion.
Get Signed MSIs Without the Manual Workflow
The signing process itself is straightforward once you have a proper MSI. The hard part is getting there from an EXE. Manual repackaging is slow, fragile, and requires packaging expertise most generalist IT admins do not have.
If you are spending hours converting EXEs before you even get to the signing step, that is the problem worth solving first. Start with a free conversion and see what the output looks like before committing to a workflow.