Partly. Apple's documentation says the notary service keeps an audit trail of software distributed with your Developer ID signing key, and that if you find unauthorized versions you can work with Apple to revoke their tickets. It narrows the damage, but it does not replace rotating the key.
What Apple says
In its notarization overview, Apple states that notarization also protects your users if your Developer ID signing key is exposed. The notary service maintains an audit trail of the software distributed using your signing key. If you discover unauthorized versions of your software, you can work with Apple to revoke the tickets associated with those versions.
That is a specific, bounded claim. It describes two things: an audit trail and ticket revocation, in cooperation with Apple.
What it does not say
The documentation does not say a leaked key becomes useless. It also does not describe what happens to software signed with the key that was never submitted for notarization. Do not assume the notary service stops every misuse.
So treat notarization as a layer that helps you find and contain misuse, not as a cure for key exposure.
Response steps
- Confirm the exposure. Work out what leaked: the private key, the p12 file, a CI secret, or access to a signing machine.
- Stop signing with it. Pause releases that use the key until you have a plan.
- Contact Apple. Use the route Apple provides for revoking tickets if you find unauthorized versions.
- Inventory what was signed. Your release records and the notary service audit trail tell you which builds the key produced. This is why keeping a log of every signed artifact matters.
- Replace the certificate. Create a new Developer ID certificate, update CI secrets, and re-sign and re-notarize your next release.
- Tell users clearly. If unauthorized builds could have reached users, explain how to verify genuine downloads.
- Find the root cause. Ask how the key got out and fix that path.
Apple notes that only one of each distribution certificate type is allowed per team, except Developer ID. That exception matters here, since you can hold more than one Developer ID certificate during a transition.
Prevention beats response
The cheapest key incident is the one that never happens. A few habits make leaks less likely:
- Keep the key in a protected store, with access limited to the release job.
- Use a dedicated keychain on CI and remove it after use, as GitHub's guidance for self-hosted runners advises.
- Limit who can edit the release workflow.
- Keep a log of every signed artifact with its hash.
Related runbooks cover the Windows side at /resources/blog/stolen-code-signing-certificate-response-runbook, and the CI storage side at /resources/blog/store-apple-signing-certificate-in-github-actions-safely.
A fair expectation for buyers
If a customer asks how you would handle a signing key leak, a good answer names the log of signed artifacts, the revocation route, the replacement plan and the user communication plan. It does not claim the problem is impossible.
Where Safeguard fits
Recording what went into each signed release makes a key incident easier to scope. Safeguard produces SBOMs and scans dependencies for each build, with a free scan at gold.safeguard.sh/scan.
Quick check
Can Apple revoke notarization tickets?
Apple says that if you find unauthorized versions of your software, you can work with Apple to revoke the tickets associated with them.
Is rotating the key still needed?
Yes. The audit trail and ticket revocation help contain misuse, but the exposed key should be replaced.
Sources
- Apple Developer: Notarizing macOS software before distribution
- Apple Developer: Certificates
- GitHub Docs: Installing an Apple certificate on macOS runners
Last reviewed: 19 October 2026.
