What Auditors Ask About Code Signing Key Custody, and How to Answer

You will learn how to prepare for security audits regarding code signing key custody, covering hardware token compliance, physical access controls, and automated pipeline integration.

The Shift in Auditor Expectations for Private Keys

When an internal auditor or an external compliance assessor examines your software supply chain, they stop treating code signing keys like generic TLS certificates. A stolen TLS certificate lets an attacker intercept traffic; a compromised code signing private key lets an attacker distribute arbitrary malicious binaries signed with your organization's trusted identity. Consequently, auditors evaluate your key custody with the same rigor applied to cryptographic keys in financial payment networks.

The regulatory landscape shifted permanently when the CA/Browser Forum updated its baseline requirements. Since June 2023, these rules apply not only to EV code signing certificates but also to standard Organization Validation (OV) code signing certificates. Software publishers can no longer store private signing keys in software-based container formats like .pfx or .p12 files sitting on unsecured build agents, shared network shares, or developer laptops. Every active private key must reside in certified hardware.

When an auditor walks into your engineering review or submits a security questionnaire, they look for three distinct pillars: cryptographic module certification, physical and logical access restrictions, and an immutable audit trail of every signing operation. If you answer their inquiries with vague assurances that your CI/CD pipelines are secure, expect a finding. You must provide specific evidence regarding where the private key lives, how it is invoked, and who can trigger a signature.

Hardware Token Compliance and FIPS-Level Attestation

The first question an auditor asks is straightforward: Where is the private key generated, and where does it reside when it is not signing? Your answer must reference hardware security modules or cryptographic hardware tokens certified to FIPS 140-2 Level 2 or higher (or Common Criteria EAL4+ equivalents). Acceptable hardware includes USB tokens and smart cards such as YubiKey FIPS devices, SafeNet eToken models, or ePass2003 hardware tokens.

Auditors will ask to see certificate purchase records and device specifications proving that exportable private key generation was impossible. Because these tokens generate the keypair internally within a tamper-evident secure element and mark the private key as non-exportable, you can demonstrate that no human—including a compromised system administrator—can extract the raw private key bytes from the device. If an auditor asks how a backup is handled, explain that hardware tokens do not permit key extraction; business continuity relies on secondary hardware tokens issued by the Certificate Authority and registered in your signing rotation rather than software backups of the key itself.

When implementing this hardware custody model on premises, you must maintain a dedicated Windows machine that stays powered on with the authorized hardware token physically plugged into a USB port. This architecture satisfies the hardware requirement precisely because the cryptographic operations occur entirely inside the physical token's secure processor. For engineering teams evaluating deployment topologies, it is important to recognize this operational reality: if your infrastructure requires zero local physical hardware and must run entirely inside a multi-tenant cloud environment without dedicated agent nodes, a local USB token setup requires a designated gateway machine. Organizations requiring automated pipeline integrations without managing physical endpoints on-site often weigh these custody requirements against cloud signing models, though local tokens remain the standard for strict organizational ownership.

Access Control, Authorization, and the Principle of Least Privilege

Hardware custody alone does not satisfy an auditor if any process running on the host machine can invoke the key. Auditors examine how your software bridge interacts with the token. If an unattended CI/CD pipeline can issue signing requests to a local service, you must prove that unauthorized local users or external network entities cannot abuse that interface.

To satisfy these controls, your signing architecture should enforce strict access boundaries. For instance, exposing a local REST API or a watched folder mechanism must be accompanied by network-level firewalls or loopback restrictions if external access is unnecessary. When integrating with automated build systems, tools like AzureSignTool-compatible proxies allow standard CI/CD runners to request signatures without exposing raw cryptographic material or granting the build agent direct control over the underlying cryptographic service.

Be prepared to show your auditor how user permissions are structured on the host operating system. If you use a software layer like OneSigner to bridge automated workflows and hardware tokens, document how that layer is locked down. The OneSigner Windows service runs as LocalSystem (it needs that account to reach the logged-on desktop session where the token is used), so the controls an auditor will look for are around it: a machine dedicated to signing, a configuration file readable only by SYSTEM and local administrators, and API callers that must present a token issued to them. Furthermore, maintain documentation showing that administrative access to the machine housing the USB token is restricted to designated security personnel, preventing rogue developers from deploying unauthorized scripts that leverage the signing slot.

Documenting the Chain of Custody and Audit Logs

An auditor's favorite phrase is show me the logs. When code signing keys are involved, proving who signed what and when is just as important as proving where the key is stored. If a malicious binary is distributed under your certificate, your incident response and audit review must be able to trace the exact build artifact, timestamp, and triggering user or pipeline.

Your custody answer must incorporate log retention policies and operational monitoring. A robust signing setup records every transaction attempt—both successful and failed—including the calling IP address or process, the file hash of the artifact being signed, and the exact timestamp returned by the trusted timestamping authority (RFC 3161). Auditors will inspect these logs to verify that:

• Signatures cannot be generated anonymously.
• Log files are rotated and protected against tampering or premature deletion.
• Failed authentication or PIN entry attempts trigger alerts to security personnel.

When using hardware tokens, remember that multiple signing requests executed simultaneously can occasionally cause slot contention if the underlying PKCS#11 driver serializes access. Your operational documentation should explain how your signing queue manages concurrent requests from multiple developers or automated build servers without dropping payloads or corrupting signature blocks.

Addressing Managed Service Providers and Third-Party Risk

Many organizations outsource their build infrastructure to third-party CI/CD platforms like GitHub Actions, GitLab CI, or Azure DevOps. When auditors review code signing workflows operating across external cloud runners, they immediately focus on third-party risk. If your private key resides on a physical token plugged into a local server on your corporate network, you must explain how cloud-based build pipelines communicate with that local hardware without violating network security boundaries.

When answering this query, detail the exact protocol used for transit. If your build agents push payloads to a local gateway via authenticated HTTPS, provide the TLS configuration details, cipher suites, and certificate pinning measures in place. For organizations that require seamless integration with code signing certificates from providers such as SSL.com, GlobalSign, or Sectigo, maintaining transparent hardware boundaries while supporting modern deployment pipelines is essential for passing compliance checks smoothly.

At One Sign Pte. Ltd., we built OneSigner to bridge this exact operational gap, allowing teams to keep their private keys on physical USB hardware tokens while exposing controlled interfaces for local automation and remote build pipelines. Whichever OneSigner plan you choose, the key never leaves the CA-issued token, which is what the CA/Browser Forum hardware requirement asks for; the rest of the audit answer still depends on your own access controls and logging.

Next Steps for Your Audit Preparation

Audit readiness is an ongoing operational discipline rather than a one-time document upload. Review your current signing architecture today and verify the physical location of your hardware tokens, audit the user permissions on your signing host machines, and ensure your logging mechanisms capture complete file hashes and timestamps for every generated signature.