Code Signing: own certificate or Microsoft Artifact Signing?
Derive the appropriate signing strategy from the trust model, delivery route and operational capability.
Code signing binds origin and integrity to an artifact: Recipients can check whether it has been changed since it was signed and which certificate the signature is assigned to. It does not check whether the code is defective. A separate certificate is suitable for key sovereignty or offline signing requirements; Microsoft Artifact Signing provides an Azure managed service for supported integrations. What matters is the trust model, CI/CD, roles, recovery and costs - not just the signature command.
Background
Release teams want to sign applications, scripts or guidelines. Which artifact types and integrations Artifact Signing supports is the current one Microsoft Learn documentation to be taken from; No blanket support for containers can be derived from this. A local key can enable offline scenarios, but creates protection, access, rotation, and emergency overhead. A managed service reduces direct key management but makes release dependent on Azure resources, identities, supported endpoints, and service status.
Technical context
Microsoft currently runs the Azure service as Artifact Signing (formerly Trusted Signing). The service manages the certificate lifecycle; documented trust scenarios and integrations as well as region, identity and account type requirements must be checked in the target tenant before use. This is a vendor information, not a promise of unchanged availability, regions or feature equivalence.
Signing is a trust building block for the release and can be used for rules App Control for Business and monitoring support. It does not replace malware scanning, code review, SBOM, testing or incident response. CRA and NIS2 require risk-based requirements; This site does not claim any explicit general signing obligation.
Decision: own certificate or artifact signing?
Trust objective
Own certificate: Own trust chain and certificate choice
Microsoft Artifact Signing: Managed profiles within Microsoft models
Artefact type
Own certificate: Determine by certificate, tooling and recipient
Microsoft Artifact Signing: Only currently documented formats and integrations
Key model
Own certificate: Control depends on CA, HSM/Token, Cloud KMS and operations
Microsoft Artifact Signing: Key and certificate lifecycle managed by Microsoft
Offline capability
Own certificate: Possible depending on your own infrastructure
Microsoft Artifact Signing: Signing job requires service access; Plan offline fallback
Identity and RBAC
Own certificate: Implement your own authorisation model
Microsoft Artifact Signing: Azure RBAC; et al. `Artifact Signing Certificate Profile Signer` and `Artifact Signing Identity Verifier`
CI/CD
Own certificate: Proprietary tooling/secrets/HSM integration
Microsoft Artifact Signing: SignTool, GitHub Actions, Azure DevOps, PowerShell, Azure PowerShell and SDK documented
Lifecycle
Own certificate: Procurement, protection, rotation and revocation yourself
Microsoft Artifact Signing: certificate profiles and managed lifecycle; Identity validation remains a process task
Volumes and Regions
Own certificate: Design capacity and availability yourself
Microsoft Artifact Signing: Check quotas and regions in the target tenant
Business Continuity
Own certificate: Provide replacement key and locking process
Microsoft Artifact Signing: Document outage, region and service change procedures
Revocation and incident
Own certificate: Operate the revocation, investigation and communication process yourself
Microsoft Artifact Signing: Align role, revocation and incident processes with service dependencies
Current requirements and prices are available on the Azure pricing page for Artifact Signing. They must be checked for the contract, region and target tenant before procurement; Specific price or quota information does not belong on this page.
What companies need to clarify specifically
- Which artifacts and trust recipients require which trust profiles?
- Which service or person is allowed to trigger a signature - and is a pipeline identity allowed to do this?
- How are release, timestamps, audit trails, revocation and rotation proven?
- Which critical releases need a tested offline or replacement process?
- How does the pipeline separate build, security review, release and signing?
Working with ADIUMENTO
Whether a signing architecture or a pilot is suitable as a project component depends on the specific order and confirmed portfolio. Product details are on Technologies and benefits Services to find.
Typical deliverables
- Decision document with trust, key and integration model;
- Role and sharing model for people and pipeline identities;
- signing, timestamp, revocation and fallback process;
- Pilot for representative artifacts and measurable operational requirements.
Limitations and dependencies
A valid signature says nothing about the defectiveness, usefulness or legal conformity of an artifact. Regions, account type requirements, certificate profiles, supported integrations, and pricing are subject to change. Before productive use, current Microsoft documentation, procurement conditions and your own restart plan must be checked. ADIUMENTO provides no guarantee of conformity or availability.
Further official sources
- What is Artifact Signing? – Microsoft Learn
- Artifact Signing integrations – Microsoft Learn
- Azure Artifact Signing product – Microsoft Azure
Orientation
Frequently asked questions
Is Artifact Signing the same as Microsoft Trusted Signing?
The current official Azure documentation refers to the service Artifact Signing; Technical metadata sometimes still contains the service name “trusted-signing”. The current Microsoft Learn documentation is relevant for architecture and procurement decisions.
Can we integrate Artifact Signing into our pipeline?
Microsoft documents SignTool, GitHub Actions, Azure DevOps Tasks, PowerShell for Authenticode, Azure PowerShell for App Control CI policies, and an SDK. A pilot should verify whether their own pipeline, region, identity and artifact type fit.
Replaces a Signature Defender or WDAC?
No. Signatures can be taken into account in trust rules. Detection, assessment, logging and response remain standalone controls; see Defender, app control, monitoring and incident response.
Next sensible step
Delineate a release path, its trust recipients, and the required recovery time. If covered by the portfolio, a pilot for signing architecture and operations can be carried out IT Security & Compliance or Services be clarified.