Security model
How your signing identity is held, who can use it, and what we can prove about every artifact that comes back. Written plainly, because you should not have to trust a diagram.
Your key is born in hardware and dies in hardware.
The keypair behind your Developer ID certificate is generated inside a dedicated hardware security token, in the token's own secure element. The certificate signing request is built from the on-device public key and submitted to Apple; the issued certificate is loaded back onto the token.
The private key never exists as a file. It never touches a disk, never appears in a backup, and cannot be exported — not by you, not by us, not by an attacker with a shell on the signing machine. The hardware performs signatures; it does not surrender keys.
There is no import path. We do not accept an existing .p12, even as a convenience. An imported key is a key that has traveled, and a key that has traveled cannot be proven uncompromised. Every identity we custody was generated on the device that holds it.
Zero secrets in your CI.
Your pipeline authenticates with a short-lived OIDC identity token minted by your CI provider — for GitHub Actions, the token GitHub itself issues to your workflow run. We validate it against the provider's published signing keys, then enforce your policy on its claims: which repository, which ref, which workflow, which actor is allowed to request a signature.
There is no long-lived credential in your repository to steal, rotate, or leak. A leaked workflow log exposes nothing. A malicious dependency's postinstall script finds nothing. The token a request carries expires in minutes and is bound to a single workflow run.
The signing machine accepts no inbound connections.
Submissions land at a control plane that validates identity and policy, then queues the job. The signing machine polls that queue outbound. It has no open ports, no public address, and no path for anyone on the internet to reach it directly.
One physical token per customer.
Your identity lives on its own token — not a slot in a shared HSM partition. Signing jobs run in isolated processes with isolated filesystems. Another tenant's job cannot see your artifacts, your certificate, or your token.
Volume caps on the signing path.
Every plan carries a hard monthly signing cap, and anomalies alert a human. If a policy check were ever bypassed, the blast radius is a bounded number of artifacts in an audit log — not a thousand signed binaries before anyone notices.
Queue instead of fail.
Signed artifacts are self-contained: the trusted timestamp and stapled notarization ticket mean your users never contact our infrastructure. If the signing machine is ever down, your job queues and completes — it does not fail your release.
A stolen token cannot sign.
Every signature requires the token's PIN, injected by our signing host and held nowhere else. A token removed from our custody locks itself after three wrong attempts and can never be unlocked — only wiped. Physical theft yields a brick, and our token-presence watchdog alarms within minutes.
Attestation you can hand an auditor.
At enrollment we capture the token manufacturer's attestation certificate for your key — cryptographic proof, verifiable by anyone, that it was generated inside the secure element and cannot be exported. It's yours to download from your portal, forever.
Every signature leaves a receipt.
Each signing job appends an entry to a hash-chained log. Each entry commits to the one before it, so history cannot be quietly rewritten. You can export the chain and verify it yourself.
input_sha256: what we received output_sha256: what we returned commit_sha: the commit your CI attested to actor: who triggered the workflow cert_serial: the certificate that signed notary_id: Apple's notarization submission policy_version: the rules in force at signing time prev_hash: hash of the previous entry
Signatures that outlive the certificate.
Every signature carries an RFC 3161 trusted timestamp and every artifact is notarized by Apple and stapled. That means your shipped builds keep verifying after the signing certificate expires, and they verify offline, on machines that have never heard of us. We are in your release path, not your runtime path.
- We never see, hold, or transmit your private key — the hardware makes this a physical property, not a policy.
- We never accept a key that was generated anywhere but on the token.
- We never place a credential of any kind in your repository or CI environment.
- We never sign without a trusted timestamp.
- We never share hardware between customers.
Apple is the sole issuer of Developer ID certificates. We custody your identity and operate your signing; we do not and cannot issue certificates, and your relationship with the Apple Developer Program remains your own. That includes revocation: the kill switch for your identity lives in your Apple account, not ours — we can never hold it hostage.
Your account's first notarization can take hours — Apple applies one-time vetting to every new identity's debut, and no vendor can speed that up. We monitor it, staple automatically the moment it clears, and tell you the truth about the wait instead of selling you speed. Every notarization after the first typically completes in minutes.
If your token were ever stolen, the recovery is orderly, not an emergency: the PIN-locked token cannot sign, we ceremony a replacement immediately, your new certificate goes live alongside the old one, and the old one is revoked on your schedule — zero downtime, no user impact. And because Apple's rules can change without warning, a weekly canary run signs and notarizes under our own identity, so changes break our test artifact before they touch your release.
Found something? Write security@signetkeys.com. We read every report, respond within two business days, and credit researchers who want credit.