Quiz Entry - updated: 2026.10.20
What are the trade-offs between giving each developer a personal code-signing certificate and sharing one certificate across the team?
Personal certificates show exactly who signed what, but mean many certificates; one shared certificate is ideal for signing releases for outsiders, but nobody can tell which developer signed a file.
| One certificate per developer | One shared certificate | |
|---|---|---|
| Accountability | Each signature names the developer | You see the certificate, not the person |
| Revocation | Revoke one person's certificate when they leave | Revoking hits everyone's signed code; a leaver has a copy of the key |
| Number of certificates | Many, each must be trusted on clients | One |
| Key protection | Each developer guards their own key | Exported as PFX and copied to all: many places to steal it from |
| Fits | Internal development and test | Releases for customers (one company identity) |
Best practice combines them: internal code is signed with personal certificates (one AD group, here GG_CH_Codesigners, may enroll from a duplicated Code Signing template), while released products are signed with a single company certificate kept in a secure container (smart card or HSM) that only a controlled build process can use, never as copies on developer machines.
Go deeper:
Wikipedia: Code signing — publisher identity and the risk of stolen signing keys.- Microsoft Learn: Certificate template concepts — controlling who may enroll via template permissions.