Code Signing for Software Companies Without an IT Team

You built software. You want to sign it so users don’t get the ‘Unknown Publisher’ warning when they install it. You don’t have a security team, an IT department, or someone whose job it is to manage certificates. You just need this to work with the least ongoing overhead.

This guide skips everything you don’t need and tells you exactly what to do. It is opinionated on purpose: there are several ways to set up code signing, but for a small team with no dedicated IT, some options are much better than others in 2026.

What You Can Skip (And Why)

Most code signing guides cover everything. You don’t need everything. Here’s what you can safely ignore as a small software company:

Step 1: Pick Your Setup (One Question Decides It)

There are three realistic options for a small software company in 2026. Answer one question to find yours:

Do you sign builds manually (you run a release script and sign yourself), or do you sign automatically as part of a CI/CD pipeline (GitHub Actions, GitLab, etc.)?

If you sign manually (or want the simplest possible setup):

Start with Microsoft Trusted Signing if you qualify. If not, use SSL.com eSigner or a Sectigo OV certificate with a physical token as a last resort.

If you sign in CI/CD pipelines:

You need a cloud signing service. A physical token cannot plug into a GitHub Actions runner. Microsoft Trusted Signing or SSL.com eSigner are the two best options.

The Three Options, Explained

Option 1: Microsoft Trusted Signing (Best for US/Canada teams)

Microsoft Trusted Signing is Microsoft’s own signing service, available through Azure. At approximately $10 per month, it is the lowest-cost option and the most natively integrated with Windows tooling and GitHub Actions.

You get: a cloud-based signing setup with no hardware, no shipping wait, and signtool compatibility. Your organization name appears in UAC dialogs. Signatures are accepted by Windows for standard software distribution.

• Cost: approximately $9.99/month (Basic tier, 5,000 signatures/month)
• Eligibility: requires an Azure account; your organization must be based in the US or Canada with at least 3 years of verifiable operating history (business registration records, tax history)
• Setup time: hours once you have an Azure account and meet eligibility requirements
• Works in pipelines: yes, first-class GitHub Actions and Azure DevOps support
• Limitation: not accepted for kernel-mode driver signing; some strict enterprise deployment policies may not accept it; US/Canada only

Option 2: SSL.com eSigner (Best for international teams or pipeline-first)

SSL.com’s eSigner is a cloud signing service available internationally. OV certificates require the standard validation process (organization exists in business registries, phone number available). The 30-day free trial is genuinely useful for testing before committing.

• Cost: approximately $20/month per OV credential after the 30-day free trial
• Eligibility: any country; organization must be registered as a legal entity with a verifiable phone number in business directories
• Setup time: 1 to 3 business days for OV validation plus a few hours of technical setup
• Works in pipelines: yes, via CodeSignTool CLI; works on Windows, Linux, and macOS runners
• 30-day free trial: the most complete free trial of any major CA signing service; use it to confirm pipeline integration works before paying

Option 3: Physical USB token (If you want hardware, don’t have CI/CD)

If you sign releases manually from a single machine and want the simplest possible credential model (a physical object you can physically secure), an OV certificate on a USB token from Sectigo or SSL.com works. You plug it in, enter a PIN, sign your release, unplug it.

• Cost: approximately $220/year via authorized resellers for Sectigo OV
• Setup time: 3 to 5 business days for OV validation plus 5 to 15 business days for shipping
• Works in pipelines: no; the token physically cannot plug into a cloud build runner
• Best for: solo developers or very small teams who sign quarterly releases manually and want the simplest possible setup with no ongoing service subscription

Step 2: The Validation Process (What Actually Happens)

OV validation is where most small companies hit unexpected friction. Here is what the CA is actually checking, and the one thing that most commonly causes delays.

What the CA verifies

• Your organization exists as a legal entity: the CA checks government business registries, national company databases, or commercial data sources like Dun and Bradstreet. Your company needs to actually exist as a registered entity. Sole traders and freelancers operating under their own name can use Individual Validation (IV) instead, available from SSL.com.
• Your organization’s address: the address you provide must match what appears in business registries. Use the registered address, not a different office or a home address if those differ from your registration.
• A working phone number in a business directory: this is the friction point. The CA needs to verify a phone number for your organization in an independent data source, not just one you provide. Mobile phone numbers and VoIP numbers do not appear in business directories. Your company needs a listed landline, or a number that appears in Google Business Profile, Yellow Pages, or a similar directory.

The phone number requirement catches more small companies off guard than anything else in the validation process. If your only business phone number is a mobile, add your number to Google Business Profile and allow 1 to 2 weeks for the listing to propagate before ordering. Alternatively, call the CA’s validation team before ordering to ask which directories they check for your country.

The validation call

After submitting your order, the CA’s validation team will call the phone number they’ve verified in their databases. Someone at your company needs to answer and confirm the certificate request. This is a brief call, typically under 5 minutes. Have the order confirmation number available. The call usually happens within 1 to 3 business days of ordering.

Step 3: Setup From Start to First Signed Build

If you chose Microsoft Trusted Signing

• Create an Azure account at portal.azure.com if you don’t have one
• Search for ‘Trusted Signing’ in the Azure portal and create a Trusted Signing account resource
• Create a Certificate Profile within the account (choose Public Trust for standard software)
• Create an Azure service principal or use your existing Azure credentials for pipeline access
• On your signing machine, install the Trusted Signing dlib extension for signtool
• Test with signtool using the dlib: signtool sign with your endpoint, account, and profile
• Add the Azure credentials as secrets in GitHub (AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET) and add the azure/trusted-signing-action to your release workflow

If you chose SSL.com eSigner

• Create an account at ssl.com
• Order an OV code signing certificate with eSigner delivery (you will be prompted for organization details)
• Complete OV validation: submit required documentation via the portal, answer the validation call when it comes
• Download CodeSignTool from ssl.com (Java-based CLI, cross-platform)
• Test signing: run CodeSignTool sign with your username, password, credential ID, and TOTP secret on a test executable
• Store credentials in your password manager and as GitHub secrets (ESIGNER_USERNAME, ESIGNER_PASSWORD, ESIGNER_CREDENTIAL_ID, ESIGNER_TOTP_SECRET)

If you chose a physical token

• Order an OV code signing certificate with USB token delivery from Sectigo or SSL.com via an authorized reseller
• Complete OV validation (same process as above)
• Wait for shipping: 5 to 15 business days after validation completes
• When the token arrives, install the token driver (SafeNet Authentication Client or equivalent) before plugging in the token
• Change the token’s default PIN using the middleware application
• Verify the certificate appears with HasPrivateKey = True using Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert
• Sign a test file with signtool, verify with signtool verify /pa

Step 4: The Signing Command (Copy This)

Regardless of which option you chose, your core signtool command for Windows executables follows this pattern. The exact authentication flags differ by provider, but the file-signing flags are identical:

The /tr timestamp flag is not optional. Without it, your signature becomes invalid when your certificate expires (within 460 days). A signature without a timestamp is a time-limited signature. Always include it. Any of the major CA timestamp servers work: timestamp.digicert.com, timestamp.sectigo.com, timestamp.globalsign.com.

Step 5: What to Store and Where

After setup, you have credentials that need to be protected. The consequences of losing or exposing them:

• Lost signing credentials: you cannot sign new releases until you set up new credentials. For a cloud service, this means revoking and regenerating API credentials. For a hardware token with a locked PIN, potentially revocation and a new certificate.
• Exposed signing credentials: someone else can sign software that appears to come from your company. Revoke immediately if this happens.

Store everything in a password manager (1Password, Bitwarden, or similar). Specifically:

• Service login credentials (username, password for ssl.com or azure)
• API keys or client secrets for pipeline access
• TOTP backup codes if using authenticator-based MFA
• For eSigner: the credential ID and TOTP secret for CodeSignTool
• For hardware token: the token PIN, the Admin PIN (separately, with a note not to confuse them), and the CA account credentials
• Certificate serial number or thumbprint (useful for revocation if needed)
• CA order reference number

Step 6: Ongoing Maintenance (This Is Minimal)

With a cloud signing service, ongoing maintenance is almost nothing. Set two calendar reminders and you’re done:

• 60 days before certificate expiry: start the renewal process. With cloud services this is straightforward. With a physical token, 60 days allows for shipping time and validation.
• Quarterly: verify your signing credentials still work by signing a test file. A credential that stops working silently (expired API token, changed password) only becomes apparent when you try to release, which is the worst time to discover it.

Under the 460-day maximum validity in effect since March 2026, you will renew approximately once every 15 months. Set that reminder now.

Total Cost Summary for Year One

These are approximate 2026 figures. Certificate pricing changes frequently. Microsoft Trusted Signing pricing is per Azure billing; you may qualify for Azure free credits that offset the cost initially. SSL.com’s 30-day free trial means year 1 effective cost is lower if you start with the trial.

The Four Mistakes Small Companies Make

• Buying EV when you don’t need it: EV is required only for kernel-mode driver signing and WHQL. If you’re not signing drivers, OV is the right choice and costs less. The EV-gives-instant-SmartScreen-reputation benefit was removed in August 2024; this is no longer a reason to choose EV.
• Ordering without a verifiable phone number: if your company’s phone number isn’t in any business directory, validation stalls. Solve this before ordering.
• Signing without a timestamp: your signatures expire with the certificate. Always use /tr. This is the most consequential operational mistake because it affects all existing users when the certificate eventually expires.
• Forgetting to renew until the certificate has expired: set the calendar reminder today. The 460-day cycle means expiry comes around faster than a 3-year certificate used to.

Frequently Asked Questions

Do I need to sign every file in my application, or just the installer?

At minimum, sign the installer that users download. For better security and to avoid ‘Unknown Publisher’ warnings when Windows loads individual DLLs or executables within the installed application, sign all executables and DLLs in the package. If you’re distributing a single installer, signing just the installer is a reasonable starting point. If your application displays individual publisher warnings for internal components, add those to your signing step.

Can I use the same certificate for multiple products?

Yes. One OV code signing certificate can sign any number of files for as long as the certificate is valid. The certificate represents your organization, not a specific product. If your company has three different applications, one certificate signs all three. There is no per-product certificate requirement for standard OV signing.

What happens if I forget to renew and the certificate expires during a release cycle?

Existing software signed before the certificate expired (with a timestamp) continues to work fine. Users who already installed it are unaffected. New installations will show ‘Unknown Publisher’ warnings because the signature cannot be verified as currently valid. You need to renew the certificate, re-sign your current installers, and push updated downloads to your website. In the meantime, your existing installed user base is not affected.

Gloria Bradford

Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.

Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.