Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Microsoft's Signing Transparency is a workload of Confidential Computing Ledger. It's a cloud-managed service that enhances trust and security in software supply chains. The service is generally available; verification through Microsoft's Signing Transparency is currently scoped to specific Microsoft services. The service addresses software supply chain threats that traditional code signing alone can't fully prevent. It builds on the Zero Trust principle of "never trust, always verify." It uses an append-only log to verifiably record each signature, with keys protected in a secure confidential computing enclave. This approach allows organizations and auditors to independently verify cryptographic proof of service releases, improving security and accountability.
The service is built on the same confidential computing platform as Azure confidential ledger, using the Confidential Consortium Framework to provide tamper-evident, cryptographically verifiable records. For details about the underlying platform, see Architecture.
For technical details about the underlying architecture, standards, and cryptographic mechanisms, see Microsoft's Signing Transparency concepts. To inspect the open-source SCITT application that runs the service, see the scitt-ccf-ledger repository.
What is Microsoft's Signing Transparency?
Microsoft's Signing Transparency maintains a public, open-source, append-only ledger of software signing events. The service acts as a verifiable notary, creating a permanent record of who signed what and when, with cryptographic proof that prevents secret modifications.
The service uses COSE envelopes compliant with the SCITT Architecture and SCITT COSE Receipts standards for supply chain security. All ledger operations use cryptographic keys created in and never leaving secure confidential computing enclaves. The service verifies signer identity against trust policies before recording events and issues tamper-evident cryptographic receipts for independent verification.
Supported services
Microsoft's Signing Transparency Ledger currently provides transparency for:
- Microsoft Azure Attestation (MAA)
- Azure Key Vault Managed HSM
- Azure confidential ledger
- Microsoft's Signing Transparency
To search the ledger for a specific service's entries, use the service identifier listed in Service identifiers for supported services.
Independent audit of Microsoft's Signing Transparency
IOActive conducted an independent security assessment of Microsoft's Signing Transparency on Azure (built on CCF) from April through June 2025. The evaluation validated strong implementation security and secure integration, and confirmed the service met its security commitments. For details, see:
- Code Review & Dynamic Fuzzing of Microsoft's Signing Transparency (IOActive blog post)
- Microsoft Signing Transparency Service Security Assessment (IOActive public-facing report, PDF)
Key capabilities
| Capability | Description |
|---|---|
| Countersigning COSE envelopes | Adds a layer of policy enforcement to signed artifacts by using COSE (CBOR Object Signing and Encryption) envelopes. Any modification to the artifact or signature breaks the countersignature, making tampering detectable. |
| Immutable Merkle tree ledger | Records all signing events in an append-only Merkle tree ledger. Each entry is cryptographically linked, preventing alteration or removal. |
| Receipts for auditing and compliance | Issues cryptographic receipts with inclusion proofs that anyone can verify, supporting compliance audits and independent verification. |
How it works
Microsoft's Signing Transparency Ledger follows this workflow:
- A Microsoft developer or build system signs code and submits the COSE_Sign1 envelope to the service.
- The service verifies the signature and signer identity against its trust policy to ensure the owning service is the one who can publish a new signing event like a Software Bill of Materials (SBOM).
- The service countersigns the envelope and records the event in the immutable ledger.
- A cryptographic receipt with inclusion proof is generated and returned.
- Anyone can independently verify the signing event (for example, SBOM) by using the receipt.
For detailed technical information about COSE envelopes, Merkle tree structures, and the cryptographic verification process, see Microsoft's Signing Transparency Ledger concepts. To learn how to perform verification, see Verify ledger integrity and inspect entries.
Why transparency matters in software supply chains
Traditional code signing verifies software comes from a trusted source but doesn't prevent bad actors from using compromised or stolen signing keys to distribute malicious updates. Modern software supply chain attacks exploit this limitation.
Signing Transparency addresses this issue by recording every signature in a tamper-evident, publicly accessible ledger. This approach creates accountability: bad actors with stolen keys can still create valid signatures, but they can't hide their signing activity from detection. Any unexpected signature becomes visible to auditors.
Key security improvements:
- Detection over prevention: Even if signing keys are compromised, unauthorized use or missing entries is detectable.
- Audit capability: All signing events are permanently recorded and verifiable by any party.
- Policy enforcement: Services can verify that all releases went through the specific signing identity channels initiated by the owning service (for example, specific identities are used to sign Microsoft service-specific builds).
Security and trust benefits
Signing Transparency provides these security capabilities:
Tamper detection: The append-only ledger and Merkle tree structure make unauthorized modifications immediately detectable. Any change to a recorded entry breaks the cryptographic chain.
Independent verification: Receipts contain cryptographic proofs that anyone can verify without contacting the service. Verifiers can confirm an artifact's signature was logged at a specific time without trusting the distribution channel.
Audit trail: All signing events are permanently recorded with metadata including signer identity, timestamp, and policy validation results. These records support compliance audits and incident investigations.
Key compromise detection: If an attacker uses a compromised signing key, the unexpected signing event appears in the public ledger. Monitoring tools can alert on anomalous signing patterns.
Rollback protection: Merkle tree receipts include freshness proofs that prevent rollback attacks. Verifiers can confirm they're seeing the latest version, not an older vulnerable release.
Hardware and firmware support: The same COSE envelope and ledger mechanisms work for firmware and hardware components, supporting end-to-end supply chain verification.
Use cases
Microsoft's Signing Transparency Ledger supports these scenarios:
- Release verification: Confirm that production releases went through the authorized signing workflow by checking receipts against the public ledger.
- Compliance auditing: Generate audit reports of all signing events for a service or time period, with cryptographic proof of each event.
- Anomaly detection: Monitor the ledger for unexpected signing patterns, such as signatures from unknown identities or off-hours activity.
- Incident response: When investigating potential supply chain compromises, verify which artifacts were signed and when.
- Firmware and hardware: Verify signatures on firmware updates, hardware security modules, and other infrastructure components.
To learn how to verify signatures for supported services, see Verify ledger integrity and inspect entries.