Sharing One Code Signing Certificate Across a Team

Can a team share one code signing certificate?

Yes, and for most teams it is the right answer. A code signing certificate identifies an organisation, not an employee, so every developer in that organisation signing that organisation's software is exactly what it was issued for. Nothing in the rules says one named person must be the only signer. What the rules constrain is where the key lives and who controls it.

The Code Signing Baseline Requirements make the subscriber promise to keep sole control of the private key, keep it confidential and protect it properly. Read that as an organisational boundary rather than a personal one. Four employees signing releases through a controlled process are inside it. A token posted to a contractor who invoices you from another company is not, and neither is a key sitting in a shared drawer that anybody in the building can open.

So the interesting question was never permission. It is mechanics: exactly how does developer number two get a signature out of a device that is plugged into developer number one's machine?

Why there is no key file to copy any more

Until mid-2023 a standard code signing certificate arrived as a PFX file with the private key inside it, and sharing it with the team meant sharing that file. From 1 June 2023 the CA/Browser Forum required the key pair for every publicly trusted code signing certificate to be generated and stored in a hardware crypto module meeting FIPS 140-2 Level 2, Common Criteria EAL 4+ or equivalent. The key is created inside the device and cannot be exported.

That single change closed every workaround people still search for. There is no PFX to email, nothing to drop into a secret manager, nothing to check into a private repository, and no way to install the same certificate twice in the ordinary sense. Certificate authorities stopped supporting browser-based key generation for these products at the same time, so the key does not touch a laptop even once on its way to you.

It also explains why so much advice about sharing code signing certificates reads as nonsense now. Anything written before June 2023 assumes a file that no longer exists. The rule applied to standard OV certificates that year; EV code signing had required hardware for years already, which is why EV teams hit the team-sharing problem long before everyone else did. The practical differences between the two are covered in EV vs OV code signing.

The USB token: one machine at a time

A token can be used on any number of computers, just never on two at once. It is a physical object: unplug it, walk it to another desk, install the middleware there, plug it in, and the certificate is available to SignTool, jarsigner or anything else that reads the system certificate store. The certificate is not bound to a machine. It is bound to a piece of plastic somebody has to be holding.

Two things make this worse in practice than it sounds. The middleware has to be installed and working on every machine that will ever hold the token, which is its own small project on mixed Windows and macOS teams, the SafeNet Authentication Client guide covers the failure modes. And the token password matters more than people expect: most tokens lock permanently after a set number of wrong attempts, and a locked token with no administrator password is a dead certificate, not a support ticket.

Teams that survive on a token almost always stop passing it around within a few months and leave it plugged into one machine, usually a build server in a locked room. That is not a failure of discipline. It is the token pattern quietly turning into the signing-host pattern, which is where this article ends up too.

Cloud signing: one certificate, one session

Cloud signing removes the physical object and replaces it with a session, which solves the geography problem and not the concurrency one. The key lives in the certificate authority's HSM; a desktop agent presents it to your machine as a virtual smart card; a mobile app supplies the one-time code that opens the session. Anyone with the account credentials and the paired phone can sign from anywhere, which is a real gain for a distributed team.

The limit people miss is that the session is singular. As of August 2026, a Certum SimplySign Desktop session runs for up to two hours and cannot be held simultaneously on two machines, so a second developer signing in takes the session rather than joining it. There is also a usage ceiling of 5,000 signatures a month on Certum's cloud code signing products, generous for releases, easy to burn through if you wire signing into every commit.

Two developers who both need to sign on a Thursday afternoon are therefore taking turns, the same as with a token. The difference is that taking turns no longer requires walking anywhere. For small teams that is often enough, and it is why cloud delivery suits two to four people who release on different days. The full storage comparison lives in cloud code signing vs USB tokens.

The four patterns teams actually use

Every team sharing one certificate ends up in one of four arrangements, and the column that separates them is not cost or security posture but whether two people can sign at the same moment. Three of the four say no. That single fact drives more release-day friction than any other property of code signing.

Row two is the one people reach for instinctively and the one worth resisting. It is the only row that buys concurrency with money instead of with design, and the thing it spends is not really money, it is the publisher reputation your users experience as the absence of a warning dialog. That trade is unpacked further down.

Sign artifacts, not workstations

The pattern that scales inverts the problem. Instead of moving the key to whoever needs to sign, you move the artifact to wherever the key already is. One machine holds the token or the cloud session, accepts unsigned files from developers and pipelines, signs them, timestamps them and hands them back. Nobody else ever touches the hardware.

The Code Signing Baseline Requirements even name this shape. A Signing Service is defined there as an organisation that generates the key pair and securely manages the private key on behalf of a subscriber, with its own obligations for protecting that key. Managed platforms sell exactly this, and a build machine in your own office running the same idea is the do-it-yourself version.

Three things fall out of it that no other pattern gives you. Requests queue instead of colliding, so two developers submitting at once both get signatures. There is a log of who asked for what, which is the question a token passed around a room can never answer after an incident. And the signing step becomes scriptable, which is the doorway to the setups described in code signing in CI/CD.

One step inside the host is not optional. Timestamping the signature with an RFC 3161 authority is what keeps signed software validating after the certificate expires; skip it and every artifact your team shipped stops verifying on the expiry date. With 460-day certificates that date is now barely over a year from issuance, which makes timestamping more load-bearing than it has ever been.

What a second certificate costs in SmartScreen

Buying one certificate per developer looks like the clean fix, and it has a hidden price that is not on the invoice. Windows SmartScreen builds publisher reputation against the signing certificate. Four certificates means four reputations climbing from zero at a quarter of the pace, and four groups of users seeing the unknown-publisher warning for longer than they otherwise would.

Microsoft provides no supported way to transfer reputation from one certificate to another, even when the organisation, the publisher name and the certificate authority are identical. Publishers discover this most often at renewal: a renewed certificate is a new certificate with a new key, and files signed with it start rebuilding reputation from scratch while previously shipped files keep the file-level history they already earned. What that looks like to users is covered in SmartScreen publisher reputation.

Concentrating every release behind one certificate is therefore not only cheaper to administer, it is what makes the reputation curve climb at all. A team that splits its signing across four certificates is asking Microsoft to form four separate opinions about the same company, using a quarter of the evidence each.

460 days, multiplied by the number of tokens

Under CA/Browser Forum ballot CSC-31, code signing certificates issued on or after 1 March 2026 max out at 460 days, down from about three years. Every certificate a team holds now needs a validation round, a fresh key on hardware and a re-provisioning step roughly every fifteen months. That arithmetic is what punishes the certificate-per-developer pattern.

One shared certificate over five years is four renewals. Four certificates over the same five years is sixteen, sixteen validation rounds, sixteen hardware provisioning steps and sixteen reputation restarts, for a team that has not grown. The dates in the calendar are the same; the work behind each one is multiplied by a number you chose at purchase.

There is an operational trap here too. A renewal produces a new certificate on new hardware, so any signing host, script or pipeline that pins a certificate thumbprint needs updating on the day. Doing that once is a calendar entry; doing it four times across four developers' machines is how a release ends up signed with a certificate that expired last week. The renewal mechanics are set out in code signing certificate renewal.

Which pattern fits your team

Team size settles this faster than any security argument, because the constraint is concurrency and concurrency is a function of how many people ship. Count the people who actually produce a release, not the people who can build the project. The number is usually smaller than expected, and it points at one row.

• One or two developers, same office. A token is fine. Keep it in one machine, agree who holds it, and write the administrator password down somewhere that survives that person leaving.
• Two to four developers, different locations. Cloud delivery. Everyone can reach it, nobody posts anything, and taking turns on the session is a mild inconvenience rather than a blocker.
• Five or more, or any pipeline that signs. A signing host holding one certificate, with the team submitting artifacts to it. This is also the answer whenever signing has to happen without a person present.
• Genuinely separate products or legal entities. Separate certificates, deliberately. Reputation splitting is the point here rather than the cost, because you want the identities to be distinct.

Whichever row fits, decide it before you order rather than after, because the storage form is fixed at issuance and moving from a token to cloud delivery mid-term means a new certificate. If you want the shape sanity-checked against how your team releases, ask our team before you buy; it is a five-minute conversation that saves a reissue.

Frequently asked questions