Orthic Labs / Notes / Distribution
Distribution · what does a signed installer mean
What Does a Signed Installer Mean on Windows and macOS?

A signed installer lets the operating system identify the publisher and detect whether the signed code changed after signing. It improves distribution trust, but it does not prove that the app is bug-free, private, secure or suitable for your work.
That boundary matters. Users are often told to look for a signature as if it were a complete safety verdict. It is one control in a chain: download origin, publisher identity, package integrity, platform checks, application permissions, runtime behaviour and updates.
What code signing proves
A valid code signature can establish two useful facts:
- Origin: a certificate connects the package to a named publisher or signing identity.
- Integrity: the signed contents have not been modified since the signature was applied.
Apple describes code signing as a way to identify the source of an app and detect changes after signing. Apple also states the limitation plainly: signing does not guarantee the absence of vulnerabilities or unsafe behaviour. See About Code Signing.
The signature therefore answers “Is this the package the signer produced?” It does not answer “Should you trust every decision inside it?”
Windows: signing, publisher identity and reputation
Windows installers distributed outside the Microsoft Store are commonly signed with Authenticode-compatible certificates or Microsoft's current signing services. The signature lets Windows inspect the signer and verify package integrity.
Microsoft's current code-signing options for Windows developers distinguishes Store signing, public certificate-backed signing and self-signed certificates. A self-signed certificate is useful in controlled development or enterprise environments where the trust root is installed, but it is not automatically trusted for public distribution.
Signing and SmartScreen reputation are related but not identical. A correctly signed new application can still encounter reputation warnings while its distribution history is limited. Do not tell users to bypass a warning blindly. Explain the publisher, source URL, exact product and verification path.
macOS: Developer ID, notarization and Gatekeeper
For apps distributed outside the Mac App Store, a normal public release uses a Developer ID signing identity and Apple notarization. Apple says its notary service scans submitted software for malicious content and code-signing issues, then issues a ticket that Gatekeeper can use. See Notarizing macOS software before distribution.
The two operations serve different purposes:
- Developer ID signing identifies the signer and seals the code against alteration.
- Notarization records that Apple checked the submitted build through its automated service.
- Stapling attaches the notarization ticket to the distributed artifact so Gatekeeper can verify it even when retrieving the ticket online is inconvenient.
Notarization is not App Store review, and it is not a promise that the product has no defects.
What a signature does not prove
| Question | Does signing answer it? |
|---|---|
| Who signed this package? | Yes, when the certificate is valid and trusted |
| Has the signed content changed? | Yes, integrity verification detects changes |
| Is the application free of vulnerabilities? | No |
| Does it keep data local? | No |
| Are all dependencies safe? | No |
| Is the publisher's privacy statement accurate? | No |
| Will the update channel remain fair? | No |
| Is the software compatible with your machine? | No |
This is why code signing belongs inside software productization rather than replacing it.
How to inspect a downloaded installer
Check the source first
Download from the publisher's exact product domain or a documented official store. Search ads, mirrors and reposted download pages can imitate a product name while distributing a different file.
Read the publisher name
On Windows, inspect the file's digital-signature details or the verified publisher shown by the installation prompt. On macOS, read the Gatekeeper dialog and confirm the application name and identified developer match the publisher's documentation.
An unfamiliar signer is not automatically malicious—a product may use a legal company name different from its brand—but the publisher should disclose that relationship.
Treat warnings as questions
A warning can reflect an unsigned package, a broken signature, an unknown publisher, a quarantined download or limited reputation. The correct response depends on the exact message. Do not normalize “right-click and bypass everything” as the installation guide.
Verify release context
Check the release date, version, platform and architecture. A valid signature on the wrong version is still the wrong download.
Keep checksums in perspective
A checksum can confirm that your file matches a published digest. But if an attacker controls both the file and the page displaying the checksum, both can be replaced. A signature rooted in a trusted identity answers a different and stronger origin question.
The update path needs the same discipline
Signing the first installer is not enough. The automatic updater becomes a future code-delivery channel and needs its own authenticated design.
A responsible update system should:
- Fetch manifests over a secure connection.
- Verify a cryptographic signature before installing payloads.
- Reject packages signed by an unexpected key.
- Preserve user data across failure and rollback.
- Identify version and release notes before or during installation.
- Keep the purchased rights described by the one-time purchase policy.
The release pipeline is part of the product's trust boundary.
What publishers should disclose
Every desktop product page should state:
- The legal publisher name users will see.
- Whether the Windows package is signed.
- Whether the macOS build is Developer ID signed, notarized and stapled.
- The official download domains.
- The supported operating systems and architectures.
- How automatic updates are authenticated.
- Where to report a suspicious or mismatched package.
“Trust us” is not a verification method. Give the user something the operating system can check.
Frequently asked questions
Is a signed installer safe to run?
Signing is evidence of origin and integrity, not a complete safety verdict. Confirm the signer, download source, requested permissions, product reputation and expected behaviour before installing.
Why does Windows warn about a signed app?
Windows trust and reputation systems consider more than signature validity. A new or uncommon file may still receive a warning. Read the exact message and verify the publisher rather than assuming either “signed means safe” or “warning means malware.”
Is macOS notarization the same as App Store approval?
No. Apple's notary service is an automated scan and signing check for distributed software. It does not apply the full App Store review process.
Can an update be signed by a different key?
Technically, products can rotate keys, but the transition must be deliberately trusted by already-installed software. An unexpected signer change without a documented migration is a reason to stop and investigate.
Verify the chain
Read what a one-time purchase should preserve and how the full productization chain works. Signing is one station. It matters because every later update passes through it.
About Orthic Labs: Orthic Labs is an independent software publisher. It turns open-source ingredients into finished, documented and supported desktop software.