Code Signing Standards and Requirements: What Software Publishers Need to Know
Code signing requirements are not one rulebook. They come from industry requirements, certificate and PKI standards, Certificate Authority policies, cryptographic rules, timestamping standards, and platform-specific signing systems.
Last reviewed: September 2026What Code Signing Standards Actually Govern
A code signing standard is a rule, specification, or policy that determines how signing credentials are issued, protected, used, or verified. Some rules govern public certificates. Others govern the cryptography, certificate structure, timestamp evidence, or the platform that consumes the signature.
The useful question is therefore not “What is the code signing standard?” It is “Which authority controls the part of my signing workflow that I am trying to satisfy?” That distinction prevents publishers from applying a CA rule to a platform that has its own signing infrastructure, or assuming that a valid certificate guarantees platform acceptance.
The Main Layers of Code Signing Standards
The standards landscape becomes easier to reason about when each layer is assigned a job. The layers overlap, but they are not interchangeable.
CA/Browser Forum requirements
Baseline requirements establish rules for publicly trusted code signing certificates and the CAs that issue them. They affect validation, issuance, key protection, certificate lifecycle, status, and related controls.
X.509 and PKI
Certificate standards describe how identity, public keys, validity, issuer information, key usage, policies, and extensions are represented so relying systems can process the credential.
Algorithms and key parameters
Signing depends on algorithms, key sizes, hashes, and signature formats that remain acceptable to the applicable standard, CA policy, toolchain, and platform.
RFC 3161 and timestamp evidence
A timestamp can provide evidence about when a signature was produced. The timestamp authority, token, certificate chain, and algorithms also have validation requirements.
Windows, Apple, Android, Java
Platforms define how signed artifacts are packaged, which identities they recognize, how trust is evaluated, and which additional controls affect installation or execution.
Provider-specific issuance rules
A public CA applies its own certificate policy and operational validation procedures within the applicable industry framework. These procedures affect what an applicant must provide and how issuance is completed.
Who Sets Code Signing Requirements?
There is no single organization that controls every code signing requirement. A publisher can encounter several authorities in the same release process, with each authority controlling a different boundary.
CA/Browser Forum Code Signing Baseline Requirements
The CA/Browser Forum Code Signing Baseline Requirements are the central industry layer for publicly trusted code signing certificates. They establish expectations for participating CAs and subscribers rather than defining every platform's signing process.
For a publisher, the operational impact appears around identity validation, certificate issuance, private-key protection, certificate status, lifecycle controls, and timestamping. The standard is therefore best treated as a compliance boundary around the public certificate ecosystem, not as a manual for signing every type of software.
Publisher controls
Provide accurate identity information, protect the private key, restrict signing access, maintain certificate and key inventory, and follow the applicable certificate and lifecycle requirements.
boundary
Issuance controls
Validate the subscriber, issue certificates under the applicable policy, maintain status information, and operate the certificate lifecycle and trust infrastructure required by the applicable rules.
Code Signing Certificate Eligibility
Publicly trusted code signing certificates are issued to eligible applicants under the current requirements and the CA's validation process. Applicant categories can include organizations and individuals, but the exact eligibility and evidence requirements depend on the certificate profile, jurisdiction, and CA policy.
Eligibility is not the same as software approval. A CA's validation process establishes that the applicant meets the applicable identity and issuance criteria. It does not amount to a general security audit of the publisher's application, installer, source code, or business practices.
Prove the legal entity
Expect identity and existence checks, address or contact verification, and confirmation that the requester is authorized to act for the organization.
Prove the person
Individual certificates use an identity-validation path appropriate to the applicant. The subject information and evidence differ from organization validation.
Meet the current CA process
The practical issuance path is determined by the CA's current policy and validation procedures. Publishers should verify the requirements before starting an application.
Organization Identity Requirements
Organization validation connects the certificate subject to a real legal organization. The evidence used by a CA is intended to make the identity information in the certificate meaningful to relying parties.
That identity check should not be confused with an evaluation of the software itself. A publisher can have a properly validated organization and still ship software that fails platform checks, contains a broken signature, or triggers a security warning.
Individual Code Signing Requirements
Individual code signing follows an identity-validation path for a person rather than a legal organization. The CA must establish the applicant's identity using the current procedures applicable to that certificate profile.
The important operational difference is the subject represented by the credential. Publishers should not assume that an individual certificate and an organization certificate have identical validation steps, subject fields, or eligibility criteria.
| Question | Organization applicant | Individual applicant |
|---|---|---|
| Whose identity is represented? | A legal organization | An individual person |
| Validation focus | Entity existence, identity, contact, and authorization | Personal identity and applicant authentication |
| Certificate subject | Reflects the validated organization identity | Reflects the validated individual identity |
| Best operational check | Ensure application records match official organization information | Ensure personal identity evidence and applicant information are consistent |
EV Code Signing Requirements
EV code signing is a certificate validation profile with enhanced identity and key-protection requirements. It should not be described as a stronger encryption algorithm or as proof that the signed software is safer.
The practical difference is in the assurance and controls around the signing credential. A publisher choosing EV should evaluate the identity requirements, private-key protection model, issuance process, and platform expectations together.
Enhanced validation
The applicant must satisfy the enhanced validation path applicable to the EV profile.
Stronger protection
EV workflows place greater emphasis on protecting the private signing key and controlling how it is operated.
More controlled signing
Issuance and signing operations can require more structured handling than a basic local certificate workflow.
Private-Key Protection Requirements
The private key is the signing authority. Anyone who can use it can potentially produce a signature that appears to originate from the certificate holder. That is why key protection is a security control, not an implementation detail.
Depending on the applicable requirements and signing model, protection can involve hardware-backed key storage, approved cryptographic modules, HSMs, remote or cloud signing, restricted access, controlled key generation, and limits on key export.
Private key
Creates the signature. It should not be treated like an ordinary configuration file or shared build credential.
- Restrict who can invoke it
- Control where it is stored
- Prevent unauthorized export where required
HSM or remote signing
The signing operation can occur inside a controlled cryptographic boundary so the private key does not need to be copied onto every build machine.
- Access policy
- Auditability
- Key lifecycle controls
Choose a certificate for your software organization
Match the certificate profile to your publisher identity and the software you distribute.
Explore enterprise code signingCurrent Key Protection Requirements
Key protection requirements can change as industry standards and CA practices evolve. Publishers should verify the current required protection level, approved cryptographic module approach, effective dates, and any transition period before designing a new signing workflow.
This is one reason a standards page should be maintained as a living reference. A signing process that was acceptable under an older requirement may need a change in hardware, storage, access control, or signing service when a new requirement becomes effective.
Cryptographic Algorithm Requirements
Code signing depends on a combination of key algorithm, key size, hash algorithm, signature format, certificate capabilities, signing tool support, and platform verification rules. RSA and ECC can both appear in modern cryptographic systems, but support is not universal across every signing workflow.
A technically valid algorithm is not automatically acceptable everywhere. CA policy, current industry requirements, platform restrictions, legacy compatibility, and toolchain support all need to be considered before a publisher standardizes on an algorithm.
Check the current minimum key size and signature/hash combination required by the target ecosystem.
Do not assume every platform, CA profile, or legacy verifier accepts the same ECC options.
Widely used for current signing workflows, subject to the exact platform and policy requirements.
Older algorithms can remain technically recognizable while being disallowed, deprecated, or unsuitable for new issuance.
Certificate Format and X.509 Requirements
X.509 defines the structure used to represent a digital certificate. The fields are not decorative metadata. They tell a verifier who the certificate represents, which public key is bound to that identity, who issued it, how long it is valid, what it can be used for, and which policies or extensions apply.
Certificate structure becomes verification input
Code Signing Extended Key Usage
Extended Key Usage, or EKU, expresses intended certificate purposes. A certificate intended for code signing should carry the appropriate code signing purpose rather than being treated as interchangeable with a credential issued for another use.
EKU is one input to certificate-purpose validation. Platforms and tools can use it alongside key usage, chain validation, certificate policies, and other checks to decide whether a certificate is appropriate for a signing operation.
What may this certificate do?
EKU helps represent the intended application of the certificate rather than leaving purpose implicit.
Is the purpose acceptable?
The verifier can evaluate certificate-purpose information as part of the overall signature validation process.
Purpose is not identity
EKU does not establish who the publisher is by itself. Identity, trust, chain, status, and signature validation remain separate checks.
Certificate Validity and Lifetime
A certificate has a defined validity interval with an issuance date and expiration date. Publishers need to track this interval for renewal and replacement, but certificate lifetime should not be confused with the lifetime of a software release that was signed with it.
Current validity requirements can change, which makes certificate inventory and renewal planning part of standards compliance rather than an administrative afterthought.
Timestamping Requirements
Production signatures are commonly timestamped so the signing event has independent time evidence. A timestamp authority returns a timestamp token that can be validated along with its own certificate chain and algorithms.
Timestamping matters because a software signature may be evaluated long after the signing certificate's validity period. The timestamp provides evidence about when the signature was made, while the verifier still needs to apply the relevant certificate-status and platform rules.
Certificate Revocation Requirements
Revocation is used when a certificate should no longer be trusted before its natural expiration. Private-key compromise, mis-issuance, subscriber problems, or other defined events can trigger revocation under the applicable rules.
For publishers, compromise is the most important operational case to plan for. Once a signing key is suspected to be compromised, the response can involve stopping signing, assessing affected releases, contacting the CA, replacing credentials, and determining how platform verification will treat existing signatures.
Why revoke?
Examples include private-key compromise, certificate mis-issuance, or a subscriber condition that requires the credential to be withdrawn.
How is status checked?
Certificate status mechanisms can include CRL and OCSP concepts, depending on the ecosystem and verification path.
What should a publisher do?
Stop unauthorized use, protect or replace the signing infrastructure, investigate affected artifacts, and follow the CA and platform response process.
Certificate Chain Requirements
A code signing certificate normally sits below an intermediate CA, which in turn chains toward a trusted root. The verifier uses this hierarchy to determine whether the issuing path reaches a trust anchor it recognizes.
The publisher's responsibility is not simply to possess a certificate. The final signing package and verification environment need the information required to build and validate the expected chain.
Platform-Specific Requirements
The same high-level concepts appear across platforms, but the signing systems are not identical. A public CA-issued certificate model used for Windows software should not be assumed to describe Android application signing or Apple's complete signing infrastructure.
CA-issued code signing certificates, Windows trust, signing algorithms, SignTool, timestamping, and platform reputation controls such as SmartScreen.
Key pairs, certificates, jarsigner, certificate chains, timestamps, Java security policies, and JDK-dependent algorithm restrictions.
Apple-issued signing identities, provisioning, entitlements, distribution controls, and applicable notarization requirements for macOS scenarios.
Application signing keys and certificates, APK/AAB signing schemes, Google Play App Signing, update continuity, and key rotation.
Compare code signing certificate options
Review available certificate options before selecting a signing approach for your release workflow.
Browse code signing certificatesMicrosoft / Windows Requirements
Windows signing commonly uses Authenticode with a code signing certificate and a private key. The publisher also has to account for the certificate chain, supported signing algorithms, timestamping, SignTool behavior, and Windows trust and reputation mechanisms.
These platform behaviors should be treated separately from the requirements a CA follows when issuing the certificate. A certificate can satisfy the CA's issuance process and still produce a Windows verification or execution problem if the artifact, chain, timestamp, signature format, or platform expectations are wrong.
Authenticode + SignTool
Use the supported signing workflow and inspect the final signature rather than assuming a successful local command means the release will verify everywhere.
Chain + Windows validation
Windows can evaluate the certificate chain and other trust signals separately from the mathematical validity of the signature.
Timestamp + reputation
Timestamping and platform reputation systems can affect how a signed application is experienced by users.
Apple Signing Requirements
Apple's ecosystem has its own signing infrastructure. Apple-issued certificates, developer identity, signing identities, provisioning, entitlements, bundle identifiers, and distribution controls work together as an ecosystem rather than as a simple copy of public CA code signing.
For applicable macOS distribution scenarios, notarization adds another control layer. The important architectural point is that a valid public CA code signing certificate does not by itself satisfy Apple's complete application signing and distribution requirements.
Android Signing Requirements
Android application signing is controlled by an application-signing model rather than being simply another consumer of a publicly trusted CA-issued code signing certificate. The signing key and certificate establish the application's signing identity and are central to update continuity.
APK/AAB format, APK Signature Schemes, Google Play App Signing, upload keys, key management, and key rotation all belong in the operational picture. Losing or changing the wrong key can affect the ability to publish updates, so key ownership and recovery procedures should be documented before production release.
APK / AAB
The application package that carries the signing information.
App signing key
The key that establishes the application's signing continuity.
Play App Signing
A Google-managed signing option that changes how production key operations are handled.
Updates and rotation
Key management must preserve the ability to ship legitimate updates under the platform's rules.
Java Signing Requirements
Java JAR signing uses a certificate and key pair with the Java signing and verification model. The standard toolchain includes jarsigner and keytool, while certificate chains, timestamps, Java security policies, algorithm restrictions, and JDK version changes can influence verification.
A signed JAR is not simply “trusted because it has a certificate.” The verifier must evaluate the signature structure, signed entries, certificate chain, timestamp evidence, algorithms, and the security policy of the Java environment.
jarsigner
Creates and verifies JAR signatures. Verification output should be treated as diagnostic evidence rather than a substitute for understanding the trust model.
Certificate path
The signing certificate needs an acceptable chain for the Java trust environment where the artifact is consumed.
JDK security rules
JDK releases can change accepted algorithms and security constraints, so old signed artifacts can encounter new verification behavior.
Standards vs CA Policy vs Platform Rules
This is the distinction that prevents most category errors. Standards describe technical or industry rules, CA policies define how a certificate provider applies issuance and validation controls, and platform rules define how a particular ecosystem signs or consumes software.
| Layer | Example | Who controls it? | Publisher question |
|---|---|---|---|
| Industry requirement | Code Signing Baseline Requirements | CA/Browser Forum | Does the public certificate ecosystem satisfy the current baseline? |
| Certificate policy | Issuance and validation rules | CA | What evidence and process does my application require? |
| PKI standard | X.509 | Standards ecosystem | How is identity and certificate information represented? |
| Timestamp standard | RFC 3161 | IETF / standards ecosystem | How is signing-time evidence represented and verified? |
| Platform requirement | Authenticode / Windows behavior | Microsoft | Will Windows accept and correctly evaluate this signature? |
| Platform ecosystem | iOS signing | Apple | Does the artifact satisfy Apple's signing and distribution model? |
| Application signing | Android app signing | Android / Google ecosystem | Will signing preserve app identity and update continuity? |
| Enterprise policy | Internal trust and signing rules | Organization | Does the release satisfy internal controls? |
What Software Publishers Need to Do
Standards become useful when they are translated into release controls. The publisher should map each requirement to an owner, a technical control, and a verification step.
From requirement to evidence
Do not keep compliance as a document-only exercise. For each requirement, identify where it is implemented and what evidence proves that the control is working.
- Certificate inventory
- Key-management record
- Signing configuration
- Timestamp configuration
- Verification evidence
- Incident and replacement procedure
What Changed in Code Signing Requirements?
Code signing requirements change because the cryptographic threat model, key-protection expectations, certificate lifecycle practices, platform behavior, and industry standards evolve. Changes can affect certificate profiles, private-key protection, algorithms, validity periods, issuance procedures, or platform compatibility.
Publishers should distinguish between an announcement, a future effective date, a transition period, and a requirement that is already enforced. Treating every announcement as an immediate production change can create unnecessary disruption, while ignoring effective dates can leave a signing pipeline non-compliant.
How to Stay Compliant When Requirements Change
Standards compliance should be maintained as an operational process. A publisher needs an owner for certificate policy monitoring, a current inventory of signing credentials, a documented migration path, and a verification step that proves the new workflow works before production rollout.
Standards Compliance Checklist
Certificate
- Correct certificate type
- Correct validated identity
- Correct purpose and EKU
- Valid certificate chain
- Current certificate and policy status
Key
- Appropriate key algorithm and size
- Required protection level
- Restricted signing access
- Secure key generation and storage
- Export controls where applicable
Signing
- Supported signing format
- Appropriate hash and signature algorithm
- Final release artifact signed
- Timestamp applied where appropriate
- Build output matches the signed artifact
Verification
- Signature validates
- Certificate chain is trusted
- Certificate status is acceptable
- Timestamp validates
- Platform-specific verification passes
Common Misconceptions
“CA/Browser Forum standards apply to every platform.”
They govern the applicable public code signing certificate ecosystem. Platform-controlled signing systems can have separate requirements.
“A CA approves my software.”
A CA validates the applicant and issues a certificate under its policy. That is not a general security audit or approval of the software.
“EV means the software is safer.”
EV describes an enhanced validation and key-protection profile. It does not certify that the software is free from vulnerabilities or malicious behavior.
“If a certificate is valid, every platform will trust it.”
Platform trust depends on the ecosystem, chain, certificate purpose, artifact format, signing model, and additional verification controls.
“A certificate expiration automatically invalidates every old signature.”
Older signatures can be evaluated using timestamp evidence and platform-specific validation rules. Expiration alone does not describe every historical-signature outcome.
“One certificate satisfies Windows, Android, macOS, and iOS.”
These ecosystems use different signing and identity models. Cross-platform release planning must account for each platform's requirements.
Frequently Asked Questions About Code Signing Standards
What are the current code signing requirements?
Who sets code signing standards?
What are the CA/Browser Forum Code Signing Baseline Requirements?
What are the private-key protection requirements?
Does code signing require an HSM?
What does a CA verify before issuing a code signing certificate?
What algorithms are supported for code signing?
Is timestamping required?
Do the same requirements apply to Android and iOS?
Are Microsoft code signing requirements the same as CA requirements?
Related Code Signing Standards Resources
The compliance boundary to remember
Why the infrastructure exists
Explains how keys, certificates, CAs, trust, and lifecycle mechanisms fit together.
What the CA does
Explains identity validation, certificate issuance, and certificate lifecycle responsibilities.
What rules must be satisfied
Explains the industry, certificate, cryptographic, timestamping, and platform requirements affecting publishers.
What changed and when
Tracks requirement changes, announcements, effective dates, and operational updates.
Build your signing process around the actual requirements
Use the standards layer to identify the rules that apply to your certificate, private key, signing workflow, timestamping process, and target platform. Then verify the final artifact under the environment where your users will consume it.
Explore Code Signing Certificates →