Application modernisation
Code signing
Code signing is the process of applying a cryptographic signature, generated from a digital certificate and its private key, to an executable, script, or package so that the operating system and the people running it can verify who published it and confirm it has not been altered since signing.
Why Code signing matters in a Microsoft estate
Code signing matters during Windows 11, Intune, Azure Virtual Desktop, and Cloud PC programmes because application blockers can delay the whole rollout. The practical question is whether the term helps capture, package, sign, deploy, or troubleshoot an app with less rework.
How Code signing shows up in practice
MSIX makes code signing a mandatory part of the format rather than an optional best practice the way it is for a traditional EXE or MSI. Windows will not install an MSIX package at all unless it carries a valid signature chaining to a certificate trusted on that device, which closes off a whole category of tampering and impersonation risk that unsigned or optionally-signed installers have always been exposed to. This also means a packaging pipeline cannot treat signing as a late, occasional step; every build that needs to reach a device has to be signed as part of the release process. The signing identity matters as much as the act of signing itself: the publisher name in the certificate becomes part of the package's identity.
Switching signing certificates, letting one certificate expire and replacing it with a differently-issued one without matching the subject name, or signing a supposedly-updated package with a different certificate than the original, breaks the update chain for devices that already have the earlier version installed, since Windows treats it as effectively a different, unrelated application rather than an update. Timestamping a signature at signing time protects against the most common operational failure mode: without a trusted timestamp, a package's signature becomes invalid the moment its signing certificate expires. A timestamped signature remains valid instead, because it can be evaluated against the certificate's validity at the time of signing rather than the current date.
This is why timestamping should be treated as a default rather than an optional signing setting. For applications distributed publicly rather than sideloaded within an organisation, the certificate's reputation also interacts with Windows SmartScreen and broader trust heuristics, where a newly issued or low-reputation certificate can trigger warnings even though the signature itself is technically valid. This effect only fades as the certificate accumulates a track record of signing software that behaves well. It is one of several reasons organisations distributing software externally often prefer an Extended Validation code signing certificate over a standard one, since EV certificates carry stronger identity verification and tend to build reputation faster.