Code Signing Readiness Checklist (CSBR)

💡 CSBR scope is publicly-trusted code signing certificates only. Internal-only signing (driver signing for managed fleets, internal app signing) is out of scope for the CA/B Forum but almost always in scope for SOX, PCI, FedRAMP, or your own internal audit.

💡 The most common scope gap: a developer issued a "just for testing" cert from a public CA two years ago, paid with a personal card, and the key is in a Downloads folder. Find these before the auditor does.

💡 CSBR effective June 2023 raised the floor: keys for publicly-trusted code signing must be generated and stored on FIPS 140-2 Level 2 (or CC EAL 4+) hardware. Soft tokens, .pfx files, and developer SmartCards no longer qualify.

💡 A "FIPS-capable" device is not the same as a device "operating in FIPS mode." The audit asks for the second. Take the screenshot.

💡 If the HSM firmware was updated after the device was originally validated, the FIPS certificate may not cover the running firmware. Track this in your inventory.

💡 Auditors ask: "Show me how a developer assigned to Project A cannot trigger a signing operation on Project B." If you can't demonstrate it in a screen share, the control is not there.

💡 Naming conventions matter for audit speed. prod-luna-codesign-ev tells the auditor everything they need to know in one line; codesign-env-1 tells them nothing and invites follow-up questions.

💡 CSBR does not mandate per-request human approval — it mandates that signing key access is properly authenticated and logged. Internal SOX, PCI, and FedRAMP overlays are usually what add the human-in-the-loop requirement. Document which control framework drives each approval rule.

💡 The most common audit finding here is a stale approver list — someone who left a year ago is still in the group. Pulling membership from AD via group sync (not manual entry) closes this gap.

💡 The auditor will pick a key at random and ask: "Show me how this key came to exist." If your answer is "I think Bob generated it back in 2022," that is a finding.

💡 Reconstructed ceremony records are acceptable for grandfathered keys, but only if the reconstruction is honest, dated, and signed off. Do not back-date a ceremony record. Ever.

💡 See the Key Ceremony Best Practices post for a full ceremony template and the Compliance-in-a-Box bundle for the RFC 3647-aligned script.

💡 Auditors will ask for "every signing event for this product line in Q3 of last year." If the answer takes more than a day to produce, that is a finding even if the data exists.

💡 A common gap: the platform logs the service account that authenticated, not the human who triggered the build. Make sure your audit chain links the build job to the human who pushed the commit / approved the release.

💡 Log retention requirements vary by audit framework. CSBR is the floor; SOX, PCI 4.0, and FedRAMP are usually longer. Document the longest applicable retention and configure to that.

💡 Without a TSA, signed software effectively rots: once the signing cert expires, the signature stops verifying and end users see "publisher could not be verified" warnings on perfectly good binaries.

💡 CSBR explicitly requires a publicly-trusted TSA for publicly-distributed software. A self-hosted TSA is fine for internal driver signing but not for anything you ship to customers.

💡 Treat TSA failures the same as signing failures in your pipeline. A green build with a missing timestamp is worse than a red build, because nobody catches it until customers install the software.

💡 This is the single most common audit finding for code signing programs. Teams design the CLM segregation correctly and then put both prod and non-prod keys on the same HSM partition because "it was easier."

💡 The test the auditor runs: "Show me, in the HSM management console, that the prod EV signing key and the dev test signing key are not in the same partition." Be able to demonstrate this in under five minutes.

💡 Partition PIN / credential handling deserves its own ceremony. Document it, then test the recovery path on a non-prod partition before you need it on a prod partition.

💡 The platform alone does not pass an audit. Auditors compare the CP/CPS narrative to the platform configuration — gaps in either direction (control implemented but not documented, or documented but not implemented) are findings.

💡 See Compliance-in-a-Box for an RFC 3647-structured CP/CPS template that maps cleanly to CodeSign Protect operations.

💡 CSBR requires CAs to revoke compromised code signing certificates within 24 hours of confirmed compromise. Your incident response timeline must be shorter than that — you need time to investigate, contact the CA, and confirm.

💡 See the Key Compromise Response Runbook for the detailed step-by-step.

💡 Your readiness percentage is auto-calculated from the progress bar at the top of this page. Use it as a self-scoring snapshot, not a substitute for the formal audit.

💡 **Scoring guide:** 90–100% = ✅ Audit-ready (controls in place, evidence available, gaps tracked) | 75–89% = 🟡 Mostly ready (small gaps, deliverable in weeks) | 50–74% = 🟠 At risk (foundational gaps, weeks-to-months of work) | Below 50% = 🔴 Not ready (do not request a CSBR audit attestation in this state)

💡 The two sections that most commonly drag the score down are Key Ceremony Evidence (for older keys) and Partition Isolation (for fast-growing programs). Address those first.