GlobalSign OV Code Signing Certificate
Understand GlobalSign Standard Code Signing, including organization validation, key-storage options, supported platforms, signing workflows, code-signing timestamping, pricing, certificate renewal process, and how it compares with GlobalSign EV.
Is GlobalSign OV Code Signing Right for You?
Start with the publisher identity, software workload and platform requirement.
Standard Code Signing is organization-first.
GlobalSign positions Standard Code Signing as the organization-validated product. The certificate is issued in the name of a legally registered organization, so the publisher identity and the organization behind the software need to match the certificate model.
That makes the first decision straightforward: identify who should appear as the publisher, then determine what the software needs to do. Ordinary application signing and supported cross-platform signing can fit Standard Code Signing. A specific Windows kernel-mode driver workflow can introduce an EV requirement.
What GlobalSign OV Actually Establishes
The certificate answers identity and integrity questions. It does not certify the software itself.
The certificate establishes a relationship between the public key and the validated organization. The private key then creates the signature over the software artifact.
The verifier can check the code-signing certificate chain and determine whether the signed artifact has changed. Timestamping adds a separate time reference that becomes useful when the signing certificate later reaches its validity boundary.
Code signing does not mean the software has been security-tested or approved by GlobalSign. It identifies the signer and protects the signed artifact's integrity.
Standard Code Signing vs GlobalSign EV
The two products overlap for ordinary software signing, but their validation and Windows driver requirements differ.
GlobalSign Standard / OV
- Standard organization validation
- Legally registered organization required
- Normal application signing
- Token or HSM deployment options
- Azure Key Vault listed as a key-storage option
- Current maximum validity of 460 days
GlobalSign EV
- Extended validation
- Legally registered organization required
- Normal application signing
- Protected private-key deployment
- EV requirement for applicable Windows Hardware Developer Center driver workflows
- Current maximum validity of 460 days
Do not choose between OV and EV by label alone. Check whether the software release requires the additional EV validation or the specific Windows driver workflow documented by GlobalSign.
Who Can Get the Certificate?
GlobalSign's current product positioning makes the applicant identity a core requirement.
How GlobalSign Validates the Organization
Validation is a staged process. Each step establishes a different part of the publisher identity.
CA validation is not signature verification.
GlobalSign validates the organization before issuing the certificate. Later, when a signed application is opened or inspected, the operating system or verifier evaluates the certificate, chain, signature and artifact integrity.
This distinction matters for troubleshooting. A certificate can be correctly issued while a release still fails verification because of a missing intermediate, invalid timestamp, unsupported signing format or platform-specific policy.
What You Need Before Ordering
The certificate order should begin with the release architecture, not only the purchase form.
The storage model changes the signing architecture. A token attached to a controlled workstation is operationally different from a customer HSM or Azure Key Vault integration used by an automated release pipeline.
From Order to First Signed Release
The issuance workflow has two halves: certificate validation process and signing-environment provisioning.
Production signing should begin only after the complete path works. A successful certificate order does not mean the build pipeline is ready. The signing application must be able to reach the protected key, select the correct certificate, obtain a timestamp and produce an artifact that an independent verifier can validate.
How the SafeNet Token Model Works
GlobalSign documents a token-based Standard Code Signing implementation using a GlobalSign-provided SafeNet eToken.
signing
credential
The token model creates a physical boundary around the signing credential. The private key is not treated as a normal file that can be copied between developer machines.
GlobalSign's installation guidance describes token initialization, key generation and certificate installation through the SafeNet environment. The operational question is who can access that token and which workstation is allowed to perform production signing.
Controlled signing from a small number of authorized environments where a physical hardware credential is practical.
How the Customer-Owned HSM Model Works
An HSM keeps the production signing key inside the organization's hardware-backed security boundary.
GlobalSign's current guidance for the customer-owned HSM workflow specifies a FIPS 140-2 Level 2 compliant HSM and a key of at least 4096 bits for that documented setup. The certificate signing request is generated from a key created inside the HSM.
This model is suited to organizations that already operate centralized key-management infrastructure. It also introduces more integration work than a token because authentication, authorization, HSM access and signing orchestration become part of the release architecture.
How Azure Key Vault Changes the Signing Workflow
Azure Key Vault is a cloud key-management option documented by GlobalSign for Standard Code Signing.
Separate build access from signing authority.
The useful architecture is not simply "put the certificate in Azure." The important boundary is the signing key and which identities are allowed to invoke it.
For enterprise signing software in a CI/CD pipeline, permissions should be narrow, signing operations should be logged, and the release pipeline should fail visibly when signing or timestamp verification fails.
GlobalSign lists Azure Key Vault as a supported key-storage choice. The exact implementation should still be designed around the organization's Azure identity, authorization and release controls.
GlobalSign OV Across Platforms
The certificate can support different signing environments, but each platform has its own signing workflow.
Common artifacts include EXE, DLL and MSI files.
Core concern: certificate selection, chain, timestamp and final file verification.Use the Java signing toolchain and a compatible keystore environment.
Core concern: keystore, certificate chain, signing and timestamping.Follow Apple's signing and packaging requirements.
Core concern: signing identity, key access and Apple verification.Apply the signing workflow required for the AIR application format.
Core concern: supported certificate and packaging workflow.Use the appropriate Microsoft Office signing workflow.
Core concern: certificate identity and macro-signing policy.Follow the current Mozilla-specific signing requirements.
Core concern: platform-specific compatibility and verification.GlobalSign OV + Windows Authenticode
Windows signing should be explained as an artifact pipeline, not as a six-item feature grid.
Test the same file you eventually sign.
Build the application and freeze the release artifact before signing. The file that passes QA should be the file that receives the production signature.
The signing stage then selects the GlobalSign certificate, accesses the protected private key, applies the Authenticode signature and requests a trusted timestamp.
Finally, verify the signed file. Check the publisher identity, certificate chain, signature status, timestamp and final file hash before publication.
build | v QA-approved EXE / DLL / MSI | v Select GlobalSign certificate | v Protected key operation | v Authenticode signature | v Trusted timestamp | v Signature + chain verification | v Publish exact signed artifact
If the workflow involves applicable kernel-mode drivers and Windows Hardware Developer Center access, compare GlobalSign EV before assuming Standard/OV is sufficient.
GlobalSign OV + Java JAR Signing
Java signing has a different toolchain, so the visual and operational workflow should be treated separately from Authenticode.
keytool | v protected signing identity | v jarsigner | v signed-release.jar | v timestamp + verification
The important distinction is the keystore and Java toolchain. A GlobalSign certificate does not remove the need to configure the Java environment correctly.
For CI/CD, keep the signing credential outside source control and ordinary build output. The signing stage should receive only the approved JAR and invoke the protected credential under controlled permissions.
GlobalSign OV + macOS Signing
Apple software signing introduces its own identities, packaging and verification requirements.
Use the platform's signing model.
GlobalSign lists Apple/macOS among supported platforms, but macOS signing is not simply Authenticode with a different file extension.
The certificate and protected key need to be available to the Apple signing environment, and the final package needs to satisfy Apple's signing and distribution rules.
For teams shipping on multiple platforms, keep certificate governance consistent while allowing each platform to use its native signing tools and verification process.
What the Timestamp Adds
A timestamp answers a different question from the certificate itself.
Certificate + signature
- Who signed the artifact?
- Has the artifact changed?
- Is the certificate chain trusted?
Trusted timestamp
- When was the signature created?
- Was the signing credential valid at that time?
- Can the signature be evaluated later under applicable rules?
GlobalSign's product material describes timestamping as part of long-term validation of signed code. That makes timestamp acquisition a release control rather than a decorative addition to the certificate.
The release pipeline should record whether the timestamp was successfully obtained and should verify the resulting timestamp along with the certificate and signature.
When a certificate eventually expires, the timestamp becomes an important part of the evidence used to evaluate when the signature was created.
How the GlobalSign Certificate Chain Is Evaluated
A signed artifact is only as understandable to the verifier as the certificate chain included with it.
The intermediate certificate is the bridge between the leaf signing certificate and the trusted root. A missing intermediate can create a verification problem even when the leaf certificate is otherwise valid.
For production releases, verify the certificate chain on a clean machine or controlled validation environment rather than only on the workstation that performed the signing.
Inspect the subject, issuer, validity, chain and timestamp of the final signed artifact. The release process should make chain failures visible before distribution.
Why Code Signing Does Not Equal SmartScreen Reputation
Publisher identity, certificate trust and Microsoft reputation are different layers.
A valid GlobalSign signature gives Windows and other verifiers evidence about who signed the software and whether the artifact changed. It does not automatically create a positive SmartScreen reputation.
Reputation can depend on broader Microsoft signals, software distribution history and security observations. Product pages should therefore avoid promising an instant warning bypass or guaranteed warning removal simply because the certificate is OV or EV.
GlobalSign Code Signing Validity in 2026
The move to a 460-day maximum changes how software teams plan certificate replacement.
Multi-year certificates
GlobalSign previously offered longer Code Signing certificate periods.
Longer issuance ends
GlobalSign states that 2-year and 3-year Code Signing certificates stopped being issued from this date.
460-day maximum
New and renewed certificates follow the shorter maximum validity under the current rules.
More frequent renewal
Certificate replacement becomes a recurring release-management task.
Do not treat expiry as an administrative email. Connect the certificate lifecycle to CI/CD, signing infrastructure, release ownership and production testing.
GlobalSign OV Pricing and Total Cost
The certificate price is only one part of the signing budget.
GlobalSign currently lists Standard Code Signing from $529 USD per year. Verify the live commercial page before publishing a price update.
The same certificate can have a very different operational cost depending on how the private key is protected and how often the organization signs software. A single workstation with a token and a centralized enterprise signing service solve different operational problems.
For commercial comparison, keep the certificate price visible but explain the infrastructure that surrounds it. This is particularly important under the current 460-day validity model because certificate replacement is more frequent than it was under the old multi-year model.
Choose the right validation level
Compare the certificate requirements before committing to a product, especially when your release includes Windows driver signing.
GlobalSign OV Renewal: What Actually Changes
Renewal is a controlled replacement event, not simply a date on a certificate.
The new certificate should be production-ready before the old certificate becomes a release blocker. With the current 460-day maximum, this process should be treated as routine release engineering.
If the Private Key Is Compromised
The response path is different from normal expiration because unauthorized signing may already have occurred.
The private key is the authority that creates the signature. If an attacker obtains it, they may be able to produce signatures that appear to originate from the organization.
The response therefore starts by preventing additional signing, followed by certificate revocation and replacement. The organization should also identify artifacts signed with the affected key and evaluate them under its incident-response policy.
Replacing the visible certificate without replacing the private key compromise private key does not remove the underlying signing risk. The replacement process needs a fresh protected key.
GlobalSign OV in CI/CD
The central architecture question is how automation can sign without receiving a copy of the production private key.
Developer commit
|
v
Build + test
|
v
Approved release artifact
|
+------------------------------+
| |
v |
Signing authorization |
| |
v |
Protected token / HSM / Key Vault |
| |
v |
Digital signature |
| |
v |
Trusted timestamp |
| |
+---------------+--------------+
|
v
Verify signature
Verify certificate
Verify timestamp
|
v
PublishGlobalSign's token, HSM and Azure Key Vault deployment models can fit different release architectures. The security objective is consistent: production signing authority should be isolated from ordinary build storage.
Authentication, authorization, signing logs, expiry monitoring and failure handling should be part of the pipeline. If timestamping or certificate verification fails, the pipeline should stop or clearly mark the release as failed rather than publishing an ambiguous artifact.
Keep production signing keys protected
Review practical approaches for limiting private-key exposure while integrating signing into build and release automation.
When Standard / OV Does Not Match the Requirement
Use the requirement to select the certificate model.
If no, the documented Standard Code Signing eligibility does not match an individual-only publisher identity.
Normal application signing, platform support, protected key storage, or a Windows driver workflow with an EV-specific requirement.
If yes, compare GlobalSign EV. If no, Standard/OV remains the organization-validated product to evaluate.
This is not a product ranking. It is a requirement map. The certificate should match the identity of the publisher, the software formats being signed, the key-management architecture and any platform-specific validation requirement.
GlobalSign OV Buying Checklist
Turn the certificate purchase into a release-readiness checklist.
GlobalSign OV Code Signing FAQ
Direct answers for buyers comparing validation, key storage, platforms, lifecycle and the OV versus EV boundary.
What is a GlobalSign OV Code Signing Certificate?
GlobalSign's current product name is Standard Code Signing. It is the organization-validated code-signing product and is issued in the name of a legally registered organization.
What does GlobalSign call its OV Code Signing product?
GlobalSign currently calls it Standard Code Signing, while its product material describes the certificate as Organization Validation.
Who can get GlobalSign Standard Code Signing?
GlobalSign states that its Code Signing Certificates are issued only in the name of a legally registered organization.
Does it require a registered organization?
Yes. The current product positioning requires a legally registered organization.
What does GlobalSign validate?
The certificate authority validates the organization identity, relevant organization information and the appropriate contact before issuance.
How much does GlobalSign OV Code Signing cost?
GlobalSign's current official product page lists Standard Code Signing from $529 USD per year. Check the live page before publishing a price update.
Does GlobalSign provide a hardware token?
GlobalSign documents a token-based implementation using a GlobalSign-provided SafeNet eToken.
Can I use my own HSM?
Yes. GlobalSign documents customer-owned HSM deployment for Standard Code Signing and specifies requirements for the documented setup.
Can I use Azure Key Vault?
GlobalSign lists Azure Key Vault among supported key-storage options for Standard Code Signing.
Can GlobalSign OV sign EXE files?
GlobalSign lists Microsoft Authenticode among supported signing environments, which covers common Windows application artifacts.
Can it sign DLL and MSI files?
Microsoft Authenticode supports common Windows artifacts such as DLL and MSI files, subject to the exact signing workflow.
Can it sign Java JAR files?
GlobalSign lists Java among supported platforms and formats.
Can it sign macOS software?
GlobalSign lists Apple/macOS among supported platforms. The exact implementation must follow Apple's requirements.
Does GlobalSign OV support timestamping?
Yes. GlobalSign describes timestamping as part of long-term validation of signed code.
How long is GlobalSign Code Signing valid in 2026?
GlobalSign currently states a maximum validity of 460 days and says 2-year and 3-year Code Signing certificates are no longer issued.
Can GlobalSign OV sign Windows drivers?
For applicable kernel-mode driver workflows requiring Windows Hardware Developer Center access, GlobalSign states that EV is required.
What is the difference between GlobalSign OV and EV?
OV uses standard organization validation. EV uses extended validation and is required for the applicable Windows Hardware Developer Center driver workflow described by GlobalSign.
Can GlobalSign OV be used in CI/CD?
Yes, when integrated with a protected signing architecture such as a token, HSM or supported Azure Key Vault model.
How do I renew GlobalSign Code Signing?
GlobalSign's current guide says the renewal option becomes available within 90 days before expiration and up to 7 days after expiration. Organization changes require a new order.
What happens if the private key is compromised?
Stop signing, assess the incident, begin the applicable revocation process, generate a fresh protected key, obtain a replacement certificate and review affected releases.
GlobalSign Code Signing Resources
The product page should lead into implementation and lifecycle resources rather than repeating the same certificate description.
GlobalSign Code Signing Certificates and GlobalSign EV Code Signing Certificate.
Use when deciding between certificate models.Windows Code Signing, Microsoft Authenticode, EXE and MSI signing.
Use when implementing Windows releases.Java Code Signing and JAR signing with the Java toolchain.
Use when signing Java releases.Token, HSM, Azure Key Vault and private-key protection.
Use when designing signing infrastructure.Expiration, renewal, timestamping and compromise response.
Use when managing production signing.Certificate chain, timestamps and platform verification.
Use when troubleshooting signed releases.Build the certificate into the release architecture
Confirm organization eligibility, select the protected key-storage model, check the OV versus EV requirement, and plan around the current 460-day certificate lifecycle.