DEV Community: Anna Shipman

Windows Credential Configuration for DigiCert KeyLocker & SMCTL

Anna Shipman — Mon, 02 Mar 2026 06:07:06 +0000

Prerequisites

Before starting the credential setup process, ensure the following components are in place. Each one plays a specific role in establishing a secure connection between your Windows environment and DigiCert's signing infrastructure.

DigiCert ONE Host Environment

The DigiCert ONE Host Environment serves as the centralized connection point between your local system and DigiCert's cloud services. It defines the API endpoint that your SMCTL client communicates with during signing and certificate management operations. A typical endpoint looks like https://one.digicert.com. This host address tells SMCTL where to send requests for certificate issuance, key management, and signing operations through the DigiCert ONE infrastructure.

DigiCert ONE API Key

The API key functions as an authentication token. When the SMCTL client connects to DigiCert KeyLocker, it presents this key to verify your identity and authorize access to your account. Think of it as a machine-readable password that grants controlled access to your DigiCert ONE resources.

You can generate an API key through the DigiCert ONE dashboard. Once generated, treat it with the same level of protection you would give any sensitive credential. Anyone with access to this key can potentially interact with your DigiCert account programmatically.

DigiCert ONE Client Authentication Certificate and Password

This certificate establishes mutual authentication between your local system and DigiCert's servers. While the API key verifies who you are, the client authentication certificate verifies that your machine itself is authorized to communicate with DigiCert's infrastructure.

The certificate is typically saved in .pem or .pfx format and is protected by a password. Both the certificate file and its password should be stored securely with access restricted to authorized users only. Unauthorized access to this certificate could allow someone to initiate signing operations from an unapproved system.

DigiCert KeyLocker Client

The KeyLocker client bridges your Windows environment to DigiCert's cloud-based Hardware Security Module (HSM). It integrates with the Windows Key Storage Provider (KSP), allowing your system to reference private keys stored securely in DigiCert's infrastructure without ever downloading them to your local machine.

This architecture ensures that your cryptographic keys never leave DigiCert's protected environment, maintaining both security and compliance requirements for code signing operations.

Administrative Access on Windows

Administrative privileges are required because the setup process involves modifying system-level settings such as environment variables, certificate stores, and credential entries. Without administrative access, installing the KeyLocker client, storing credentials through Windows Credential Manager, and syncing certificates will either fail or produce restricted configurations that prevent successful signing.

Recommended: How to Configure DigiCert KeyLocker on Windows?

Steps to Set Up Credentials

1. Choose a Credential Storage Method

DigiCert supports four methods for storing credentials on Windows. Each method balances convenience and security differently, so the right choice depends on your environment and workflow.

Windows Credential Manager is the most secure option for interactive use. It encrypts credentials under your Windows user profile, making them accessible only when you are logged in. This is the recommended approach for most users.
Properties File stores credentials in a .properties file that SMCTL reads automatically. This method is better suited for automated signing workflows and CI/CD build systems where interactive login is not practical.
Temporary Environment Variables exist only for the duration of your current terminal session. Once you close the window, the variables disappear. This is appropriate for one-time signing tasks or isolated sessions where credentials should not persist.
Persistent Environment Variables are stored permanently in your system environment. This method is generally discouraged because the values are visible to anyone with access to your system's environment configuration, creating an unnecessary security exposure.

2. Store Credentials Using Windows Credential Manager

Windows Credential Manager encrypts your credentials and ties access to your Windows user account. This prevents credentials from being stored in plain text anywhere on the system.

Open either Command Prompt or PowerShell with administrator privileges. Run the following command to add your credentials:

cmdkey /add:digicert.one /user:<username> /pass:<api_key_or_password>

To verify that the credentials were stored correctly, navigate to Control Panel → Credential Manager → Windows Credentials. Your DigiCert entry should appear in the list.

This method ensures that your API key and certificate password remain encrypted at rest and are only accessible under your authenticated Windows session.

3. Set Up Temporary Environment Variables

For short-lived signing sessions, you can define environment variables directly in your PowerShell or Command Prompt window. These variables exist only within that session and are automatically discarded when the window closes.

$env:DIGICERT_ONE_HOST = "https://one.digicert.com"
$env:DIGICERT_ONE_API_KEY = "<your_api_key>"
$env:DIGICERT_ONE_CLIENT_CERT_PATH = "C:\Certs\client_auth_cert.pem"
$env:DIGICERT_ONE_CLIENT_CERT_PASSWORD = "<your_password>"

This approach works well in secure build pipelines or on isolated virtual machines that are reset after each deployment cycle. Because the variables are never written to disk, there is no residual credential exposure after the session ends.

4. Use a Properties File for Automated Systems

In CI/CD environments or automated build systems where no one is present to enter credentials interactively, a properties file provides a practical alternative.

Create a file named smctl.properties in a secure directory. The default location SMCTL checks is:

C:\Users\<Username>\.signingmanager\smctl.properties

Add the following content to the file:

DIGICERT_ONE_HOST=https://one.digicert.com
DIGICERT_ONE_API_KEY=<your_api_key>
DIGICERT_ONE_CLIENT_CERT_PATH=C:\Certs\client_auth_cert.pem
DIGICERT_ONE_CLIENT_CERT_PASSWORD=<your_password>

After saving the file, restrict its permissions so that only the specific Windows user account running the build process has read access. This prevents other users or services on the same machine from reading your credentials.

This method integrates well with automated pipelines where code signing is embedded as a build step and human interaction during the process is not feasible.

5. Why Persistent Environment Variables Are Not Recommended

While it is technically possible to store credentials permanently using the setx command, doing so creates a significant security risk. Persistent environment variables are visible to anyone who can access the system's environment configuration through System Properties or the command line.

Storing sensitive values like API keys and certificate passwords in persistent environment variables means they remain exposed indefinitely, even across reboots and user sessions. This method should only be considered in fully isolated, non-production environments where the machine has no exposure to unauthorized users.

6. Verify Your Configuration

After completing the credential setup using any of the methods above, verify that everything is working correctly by running an SMCTL command. For example:

smctl keypair list

If the configuration is successful, SMCTL will connect to DigiCert KeyLocker and return a list of available key pairs associated with your account.

If the command fails or returns an authentication error, check the SMCTL log files for detailed diagnostic information. Logs are located at:

C:\Users\<Username>\.signingmanager\logs

The log entries will indicate which credential source SMCTL attempted to use during execution - whether it pulled from the Windows Credential Manager, a properties file, or environment variables. This information is helpful for identifying misconfigurations or credential storage conflicts when multiple methods are present on the same system.

Source - How to Setup Credentials for Windows to Use DigiCert KeyLocker & SMCTL?

Windows BSM: Tightening App Trust & Code Signing

Anna Shipman — Mon, 23 Feb 2026 05:05:28 +0000

The New Update

With an ever-increasing demand for additional security from today's technology platforms, Microsoft is implementing several new measures to build a more robust ecosystem by default.

The most notable of these enhancements is the Windows Baseline Security Mode (BSM), which is one of several initiatives that the company is pursuing in order to provide greater runtime integrity, more restrictive execution controls, and better methods for establishing an application's trustworthiness when it is running on the platform.

While those changes affect an organisation's software configuration in considerable ways, they will also significantly affect its software publishing and development practices, including software release processes, signing practices, and overall software lifecycle management.

Introducing Secure-by-Default Execution

The Baseline Security Mode is designed to provide runtime Integrity assurances. The model limits execution to authorised applications, services, and drivers only to prevent tampering and unauthorised changes to systems. This will help ensure that systems remain intact while also giving administrators the ability to grant exceptions when operational requirements dictate flexibility.

In terms of the practical side, it is apparent; Trust must be verifiable.

This is consistent with Microsoft's expressed intention regarding the visibility of enforcement:

Developers can verify whether there are currently any active protections as well as the exception granted to developers, to understand how and when their applications will be running, according to Distinguished Engineer, Microsoft VP Logan Iyer.

As an implication of this direction, expect Trust Enforcement to be verifiable and auditable within the runtime; therefore, there will be more expected friction or outright blocks to Unsigned and/or poorly managed binaries.

Code Signing will Become Mandatory

There are already operational impacts at many organisations that either develop or distribute software:

Unsigned applications will become blocked by default policy baselines.
Execution policies continue to move to certificate-based trust chains.
Code signing must be an integral part of the developer/release pipelines.

Code signing is now integral for any applications that have historically been delivered without code signing. This will increase the costs (both monetary and time/effort) for independent or hobbyist developers as they will need to utilise code signing certificates or risk having their applications blocked based on policy.

As such, organisations will need to implement a system to manage code signing (such as a certificate management process) as well as a certificate rotation/revocation policy.

In practice, this will require organisations to integrate certificate provisioning, signing automation, and compliance with CI/CD workflows, as opposed to viewing them as an option for future use.

Baseline Security Mode in Microsoft 365 Environments

While Windows enforcement focuses on runtime integrity, BSM also appears within Microsoft 365 administration contexts, emphasising configuration hardening at the tenant level.

Microsoft has begun rolling out Baseline Security Mode through the Microsoft 365 Admin Center, where it bundles recommended configurations across collaboration and identity services into a single management dashboard. Administrators can assess vulnerabilities, simulate changes, and apply policies gradually rather than forcing immediate disruption.

Characteristics:

Coverage of roughly 18-20 policies spanning authentication, application, and file protection domains
Enforcement of phishing-resistant MFA methods for administrators
Blocking of legacy protocols and risky behaviors, such as insecure document paths
Phased activation through simulation reports and approval workflows

These controls are designed to surface configuration gaps early and reduce exposure to credential attacks and misuse scenarios.

Example Navigation Path to enable BSM (Microsoft 365)

Administrators typically activate the feature via:

Open Microsoft 365 Admin Center
Go to Org Settings
Select Security & Privacy
Access Baseline Security Mode dashboard
Run simulation/report
Approve phased policy application

The dashboard tracks posture status and allows staged enforcement, supporting adoption without sudden workflow disruption.

First Published On SignMyCode - Windows Baseline Security Mode (BSM) Raises the Bar for Application Trust and Code Signing

Secrets Management and Managers

Anna Shipman — Thu, 05 Feb 2026 10:58:53 +0000

Meaning

Secrets management is simply the process of securely storing, accessing, rotating, and auditing your digital secrets. It's one of the most important things your team can do to stay safe.

Why does it matter so much?

It reduces breach risk. No more leaked API keys on GitHub that hackers scoop up.
It ensures compliance. PCI DSS, HIPAA, and GDPR auditors love clean secrets management.
It keeps DevOps teams efficient. No more wasting hours digging for lost credentials or fixing broken pipelines because a password expired.

Think of secrets management as a digital vault. But not just any vault. This one doesn't hand out all the keys at once. Instead, it gives the right key to the right person at the right time. And when that key's no longer needed? The vault takes it back, rotates it, and locks it down again.

Different Types of Secrets Managers?

Not all secret managers are built the same. In fact, there are three main categories you'll see in the wild, and knowing the difference can save you time, money, and a lot of headaches.

Cloud-Native Secrets Managers

These are the tools built directly into your cloud provider.

AWS Secrets Manager
Azure Key Vault
Google Secret Manager

They're easy to set up if you're already living in one ecosystem. The upside? Seamless integration. The downside? You're locked into that provider. If you're multi-cloud, managing secrets across different platforms can get messy (and expensive).

Managers of Third-Party Secrets.

Imagine them as a standalone set of vaults that are cross-environmental.

HashiCorp Vault (the heavyweight champion, enterprise-grade)
Doppler (easy to use, start-up friendly)
1Password Secrets Automation (underdeveloped on the 1Password ecosystem)

They are scalable, elastic, and strong. The trade-off? Additional installation, higher price, and occasionally increased training.

CI/CD Platform Secrets Stores.

They are directly constructed into your pipelines.

GitHub Actions Secrets
GitLab CI/CD Secrets

These are handy, drop a pin, and use up your pipe. But here's the catch. They're basic. Access controls, auditing, and rotation are restricted. Good with small groups, dangerous with companies.

In other words:

Cloud-native = simple, but locked in

Third-party = powerful, but complex

CI/CD stores = convenient, but limited

Source

What is Secrets Management? Types, Challenges, Best Practices & Tools

AWS KMS Vs Azure Key Vault Vs GCP KMS

Anna Shipman — Thu, 29 Jan 2026 05:19:45 +0000

If you're using a major cloud provider, you'll almost always end up with one of three services for managing encryption keys:

AWS Key Management Service (KMS)
Azure Key Vault
Google Cloud Key Management Service (Cloud KMS)

All three:

Are secure
Are battle‑tested at massive scale
Have strong compliance stories

The mistake most teams make isn't picking an "insecure" option. It's picking the wrong fit for their environment and workflows.

Below is a breakdown, with plain language on what actually matters in real projects.

1. Key Lifecycle Automation

What this covers: key creation, rotation, expiry, and policy management.

AWS KMS

Automatic key rotation (typically yearly) is built-in and easy to enable.
Strong IAM-based policy control for who can use which keys.
Works very naturally with AWS-native services (S3, RDS, Lambda, etc.).

Azure Key Vault

Solid rotation support; can be wired tightly into Azure AD identities and RBAC.
Good fit when your identities and access policies are already in Azure AD (e.g., M365-heavy shops).

GCP KMS

Very flexible rotation schedules and policy control.
Designed with "automation-first" in mind (API-driven everything).
Plays well with infrastructure-as-code and automated pipelines.

How to think about it:

If you want very simple, AWS-native rotation, AWS KMS is smooth.
If you live in Azure AD and RBAC, Azure Key Vault feels natural.
If your environment is heavily automated and API-driven, GCP KMS has the edge.

2. HSM (Hardware Security Module) Options

What this covers: where keys live, and whether they're backed by dedicated hardware.

AWS KMS

Uses AWS-managed HSMs under the hood.
For stricter needs, there's AWS CloudHSM (dedicated HSM clusters you manage).

Azure Key Vault

Has Azure Managed HSM for customers needing FIPS-compliant, hardware-backed isolation.
Key Vault (standard) + Managed HSM cover most enterprise use cases.

GCP KMS

Offers Cloud HSM for hardware-backed key protection.
Can keep keys in HSM-backed key rings for higher assurance.

How to think about it:

All three offer HSM-backed options. If you need customer-managed HSM clusters, AWS CloudHSM is a strong option. If you just need "hardware-backed, compliant, and managed for me", all three are fine, pick based on the rest of your stack.

3. Integration Ecosystem

What this covers: how well the service integrates with the rest of the platform and common workloads.

AWS KMS

Deep, first-class integration with pretty much every AWS service.
Ideal if your workloads are mostly in AWS: S3, RDS, DynamoDB, Lambda, ECS/EKS, etc.

Azure Key Vault

Best fit for Microsoft-centric environments:
- Azure VMs, AKS, SQL Database
- Office 365 / M365 scenarios
- Windows / .NET-heavy shops
Strong for hybrid setups using on-prem + Azure.

GCP KMS

Plays nicely with:
- Kubernetes (GKE and beyond)
- AI/ML workloads
- BigQuery and data analytics pipelines
Very API-driven, easy to plug into non-GCP workloads too.

How to think about it:

If you are "mostly AWS," use AWS KMS.
If you're "Microsoft shop + hybrid," Key Vault is the natural fit.
If you're doing data/AI/Kubernetes-heavy work, GCP KMS integrates cleanly.

4. Multi-Cloud Support

What this covers: how well each can handle keys for workloads outside its "home" cloud.

AWS KMS

Primarily AWS-centric.
You can call AWS KMS from other clouds, but that's not the main design goal.

Azure Key Vault

Azure Arc and Azure AD make it easier to stretch into multi-cloud and on-prem.
Can be a good central point for identity and key management in hybrid setups.

GCP KMS

Very API-first, fairly cloud-agnostic.
Commonly used in multi-cloud environments where automation and open tooling are a priority.

How to think about it:

For pure single-cloud, pick the native solution.
For hybrid enterprise with strong identity governance, Azure Key Vault has an advantage.
For automation-heavy multi-cloud builds, GCP KMS often feels more natural.

5. Performance & Latency

What this covers: how quickly the KMS responds to encryption/decryption/sign requests.

AWS KMS

Fast and globally replicated.
Good enough performance for most application workloads, including serverless.

Azure Key Vault

Strong performance, especially when your workloads run close to it (Azure regions, hybrid with ExpressRoute/VPN).
Can add some overhead if used very frequently in tight loops without caching.

GCP KMS

Optimized for distributed, automation-heavy workloads.
Often the smoothest fit for high-volume, API-driven operations.

How to think about it:

For normal application use, all three are fine. If you're pushing very high request rates from automated systems, GCP KMS can be slightly more comfortable out of the box.

6. Pricing Model

What this covers: how you pay: per key, per request, and how predictable that feels.

AWS KMS

Usage-based pricing plus per-key costs.
Generally predictable, but can surprise you if you create too many keys or have very chatty workloads.

Azure Key Vault

Mixed pricing: operations, key types, and separate tiers (e.g., Managed HSM).
Can be confusing without a careful estimate.

GCP KMS

Usage-based and relatively straightforward.
Often seen as more predictable for automation-heavy and high-volume use.

How to think about it:

If you hate surprises, model your workload before choosing. GCP KMS is often the simplest to reason about. Azure's can feel the most complex; AWS is in the middle but very well documented.

7. DevOps & Automation Friendliness

What this covers: how easily you can manage keys via code, CI/CD, and IaC.

AWS KMS

Works well with CloudFormation, CDK, Terraform, and serverless tooling.
Strong choice for serverless architectures and GitOps-style workflows in AWS.

Azure Key Vault

Good integration with Azure DevOps, GitHub Actions, and ARM/Bicep/Terraform.
Fits well into existing Azure CI/CD pipelines and enterprise DevOps setups.

GCP KMS

Very strong for automation-heavy pipelines:
Terraform, gcloud, Deployment Manager, Cloud Build, etc.
APIs are designed to be automated first, manually managed second.

How to think about it:

All three are automatable. If your mindset is "everything as code + heavy automation," GCP KMS is a very natural fit. If you're already deep into AWS serverless or Azure DevOps, stick with the native one.

8. Audit Logging & Visibility

What this covers: who did what with which key, and how easily you can see that.

AWS KMS

Integrates with CloudTrail for detailed auditing.
Easy to track which principal used which key and when.

Azure Key Vault

Tight integration with Azure Monitor and Defender for Cloud.
Good centralised security view if you already rely on Azure's monitoring stack.

GCP KMS

Uses Cloud Audit Logs for tracking key usage.
Integrates well with Cloud Logging and SIEM solutions.

How to think about it:

They all log well. Choose based on which logging/monitoring stack your security team is already invested in: CloudTrail, Azure Monitor, or Cloud Logging.

9. Compliance Certifications

What this covers: formal standards and regulatory frameworks supported.

AWS KMS

Broad coverage: HIPAA, PCI-DSS, FedRAMP, DoD, and more.

Azure Key Vault

Very strong enterprise compliance portfolio, especially for large regulated organisations.

GCP KMS

Strong coverage, particularly for regulated and data-sensitive workloads.

How to think about it:

If you're in a regulated industry, you'll likely find what you need on all three. The real differentiator is usually your organisation's existing cloud compliance stance: most enterprises standardise on one primary cloud to simplify audits.

10. Secrets and Certificate Management

What this covers: beyond keys: managing secrets and TLS certificates.

AWS

AWS KMS is mostly about keys.
AWS Secrets Manager handles secrets; ACM handles certificates.
This gives separation of concerns but spreads functionality across services.

Azure Key Vault

Best-in-class "all-in-one":
- Keys
- Secrets
- Certificates
Convenient if you want a single place to manage all three.

GCP

Cloud KMS for keys.
Secret Manager for secrets.
Certificates handled via other services/integrations.
Similar separation to AWS.
How to think about it:

If you want one central place for keys, secrets, and certs, Azure Key Vault is designed for that. If you prefer separate, specialised services, AWS and GCP follow that model.

So… Which One To Use?

Here's a simple way to choose based on environment type:

Mostly AWS, serverless or AWS-native workloads

Use AWS KMS (plus Secrets Manager as needed).
You'll get the deepest integration with the least friction.

Microsoft-heavy, hybrid enterprise (on-prem + Azure + M365)

Use Azure Key Vault (and Managed HSM where required).
Azure AD integration and hybrid support will make your life easier.

Kubernetes-first, data/AI-focused, automation-heavy, or multi-cloud

Lean towards GCP KMS.
API-first design and strong multi-cloud usage make it a good automation backbone.

If you already know which cloud is your primary and where your identity and CI/CD live, the choice usually becomes obvious. All three are solid; the right one is the one that best matches how your systems — and your teams - already work.

Inspiration

AWS KMS Vs Azure Key Vault Vs GCP KMS: Choose the Best Cloud Security Storage

Configure DigiCert KeyLocker KSP Library

Anna Shipman — Tue, 13 Jan 2026 10:13:30 +0000

1. Download the DigiCert KeyLocker KSP Library

If you've already installed the Windows Client Installer, congratulations, the KSP is already downloaded and registered for you.

But if not, here's what to do:

Log in to your DigiCert KeyLocker portal.
In the KeyLocker menu, go to Resources → Client Tool Repository.
Find the latest KSP version that matches your OS.
Click the download icon.

Once downloaded, install it just like any other Windows application.

2. Register the KSP Library

Now let's get it recognised by Windows. Open Command Prompt (with admin privileges), then run:

smctl windows ksp register

This command registers the DigiCert KeyLocker KSP with Windows CryptoAPI.

Also Read: Learn How to Renew a Code Signing Certificate

3. Check the KSP Installation

To make sure it is all configured properly, execute this command:

certutil.exe -csp "DigiCert Software Trust Manager KSP" -key -user

This confirms that your system is capable of verifying successfully with the DigiCert KeyLocker service. In case it does not crash, congrats! Your KSP is up, and you can sign safely.

4. Synchronise Certificates

Now, for your signing tools to actually access the private keys (stored safely in KeyLocker), you'll need to sync your certificates to the local store.

Don't worry, this doesn't move your private key. It stays secure in DigiCert's cloud. You're just syncing the certificate metadata.

Run this command:

smctl windows certsync

Then, open Certificate Manager to check:

certmgr.msc

Make sure you're viewing the correct user account. Each Windows account has its own certificate store. If you can see your certificate listed there, you're good to go.

5. Start Signing

Now comes the exciting part. Actually signing your files.

For example, to sign an executable:

signtool sign /n "Your Certificate Name" /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 yourapp.exe

Your signing request goes securely through the KSP library to DigiCert KeyLocker, signs the hash, and returns the signature.

Reference

What is KSP Library? How to Configure DigiCert ® KeyLocker KSP Library?

Sign an EXE file with Azure Trusted Signing

Anna Shipman — Wed, 07 Jan 2026 09:25:14 +0000

What you'll need

Before you begin, you need the following:

A Trusted Signing Account

Before you start, you need to create a Trusted Signing account from the Azure Portal. This account is the basis of your signing environment, and it identifies where your certificate profiles, policies, and permissions will exist.

You cannot generate or use Azure's short-lived code signing certificates without first having this account.

Identity Validation

After this, Microsoft requires you to go through identity validation to ensure that your signatures will be publicly trusted.

You can validate for yourself, as an Individual, which is for the personal developer, or as an Organization which is strongly suggested for businesses, enterprises, and development teams. Validating either way allows Azure to issue trusted short-lived certificates on your behalf.

A Certificate Profile

Next, you must create a certificate profile, which is the template Azure will use to create your short-lived code signing certificates automatically. The profile defines the type of certificate, the usage policies for the certificate, and the signing algorithms in use.

On each signing action, Azure will create a new secure time-limited code signing certificate based on this profile that you can use to sign the EXE.

Required IAM Roles

To be able to perform signing actions, your Azure identity is required to have the appropriate IAM roles assigned.

At a minimum, two roles need to be assigned: the Trusted Signing Identity Verifier, which verifies that you can act on behalf of the signing account, and the Trusted Signing Certificate Profile Signer, which allows your identity to request signing certificates from the certificate profile.

If the required roles are not assigned, your signing actions will fail because you lack the proper permission scope.

Supported Operating Systems

Finally, you will need to have the signing tools running on a supported operating system, as Azure Trusted Signing tools only run in modern environments.

As it currently stands, the supported operating systems are functioning on Windows 10 version 1809 or later, Windows 11, and any version of Windows Server 2016 or newer.

If the tools are run on unsupported operating systems, then the tools may not work as expected, or the signing process may be entirely blocked.

Also Read: How to Generate CSR, Keys and Import Code Signing Certificate in Azure KeyVault HSM?

Setting Up Azure Trusted Signing

Below is how to set everything up, based on the information from Microsoft's official documentation and the technical workflows we reviewed and analyzed above.

Step 1: Create an Azure Account & Subscription

Go to Azure Portal
Create a new account or log into an existing account.
Create a subscription for Pay-As-You-Go.

Step 2: Create a Trusted Signing Account

In Azure Portal, search for Trusted Signing Accounts

Click Create

Provide: Account name, Region and Pricing tier

Complete creation
Make note of the Account Endpoint URI using Copy (you will need that in later steps).

Step 3: Assign IAM Roles

Azure requires explicit permission to be able to do any signing account operations.

You need to assign the following:

Trusted Signing Identity Verifier – Reviewing and managing identity validation
Trusted Signing Certificate Profile Signer – To authorize applications or users signing EXEs

You will assign after a trusted signing account → access control (IAM).

Step 4: Validate Your Identity

In the Trusted Signing account, go to Identity Validations.

Select Individual or Organization from the list.
Provide the requested business documents.
Then the wait for Microsoft to verify your identity may be hours to days. Depending on the level of verification.

Once approved, you can begin to make Certificate profiles.

Step 5: Create a Certificate Profile

Go to Certificate Profiles

Click Create Profile
Choose Public Trust
Select your verified identity
Name the profile and save

This profile will generate short-lived certificates when you sign your EXE.

Signing Steps (After Setup)

Step 6: Install Trusted Signing Client Tools

Install using WinGet (recommended):

winget install -e --id Microsoft.Azure.TrustedSigningClientTools

This installs:

SignTool plugin
.NET 8 runtime
Azure CodeSigning dlib
Visual C++ redistributable

Also Read: Microsoft Azure DevOps MCP Server

Step 7: Create Metadata JSON (Required)

Create metadata.json:

{
  "Endpoint": "https://weu.codesigning.azure.net",
  "CodeSigningAccountName": "YourAccountName",
  "CertificateProfileName": "YourCertificateProfile",
  "CorrelationId": "build-001"
}

Use your actual region endpoint (EastUS, WestEurope, etc.).

Step 8: Sign Your EXE Using SignTool

Use this command to sign the executable:

signtool.exe sign /v /debug /fd SHA256 ^
/tr "http://timestamp.acs.microsoft.com" /td SHA256 ^
/dlib "C:\Path\Azure.CodeSigning.Dlib.dll" ^
/dmdf "C:\Path\metadata.json" ^
YourFile.exe

Source

Code Signing an Electron.js App for macOS

Anna Shipman — Tue, 16 Dec 2025 10:17:13 +0000

Enroll in the Apple Developer Program

Before you can sign anything, notarise anything, or even whisper the words “macOS distribution”, Apple needs to know who you are. And no, just having a Mac or an Apple ID isn’t enough. You need to officially join the Apple Developer Program.

How to Enroll:

Visit the Apple Developer Program page. This is where it all begins. Apple gives you access to certificates, signing tools, TestFlight, and more.
Sign in with your Apple ID. If you don’t have one yet, create one. It’s free and quick.
Enrol in the program and pay the annual $99 fee. That’s right $99 per year for official Apple recognition.

Generate Your Code Signing Certificate

This is the digital signature that proves to macOS, “Hey, this app really came from you.” And the best part? You can get it in two simple ways.

Method 1: The Xcode Way

If you’re using macOS (which you should be for signing), Apple makes it super simple through Xcode.

Here’s how:

Open Xcode on your Mac.
Go to Xcode → Settings (or Preferences) → Accounts.
Add your Apple ID if you haven’t already.
Select your developer team.
Click Manage Certificates.
Hit the “+” button → Choose Developer ID Application Certificate.

Xcode automatically requests and installs your certificate for you.

Method 2: The Apple Developer Portal

Prefer the manual route? Here’s how to do it directly from the web:

Visit Apple’s Certificates, Identifiers & Profiles
Click the “+” button to create a new certificate.
Choose Developer ID Application as your certificate type.
Follow the on-screen steps to upload your CSR.
Download the generated certificate.
Install it by double-clicking it, and it’ll show up in your Mac’s Keychain Access.

Set Up Your Electron.js Project for macOS Signing

Install electron-builder by running this command

npm install electron-builder --save-dev

Wire up your build script

Add a script to package.json so you can build with one command:

{
"scripts": {
"build": "electron-builder --mac"
}
}

Add macOS build config

You can keep it in package.json under “build” or in electron-builder.yml. Use whichever you prefer.

Option A - package.json config

{
"name": "my-electron-app",
"version": "1.0.0",
"build": {
"appId": "com.example.myapp",
"productName": "MyElectronApp",
"files": [
"dist/**/*",
"node_modules/**/*",
"main.js",
"package.json"
],
"mac": {
"target": ["dmg", "zip"],
"category": "public.app-category.utilities",
"icon": "build/icon.icns",
"hardenedRuntime": true,
"entitlements": "build/entitlements.mac.plist",
"entitlementsInherit": "build/entitlements.mac.plist",
"identity": "Developer ID Application: Your Name (TEAMID)"
},
"afterSign": "scripts/notarize.js"
}
}

Option B - electron-builder.yml

appId: com.example.myapp
productName: MyElectronApp
files:
- dist/**
- node_modules/**
- main.js
- package.json
mac:
target:
- dmg
- zip
category: public.app-category.utilities
icon: build/icon.icns
hardenedRuntime: true
entitlements: build/entitlements.mac.plist
entitlementsInherit: build/entitlements.mac.plist
identity: Developer ID Application: Your Name (TEAMID)
afterSign: scripts/notarize.js

Sign Your App

Electron apps can be signed using electron-builder or manually via codesign:

Using electron-builder

If your certificate is installed and your config is set, this is all you need:

npm run build

Have Your Application Notarised

MacOS does not consider your Electron app to be entirely safe until you have signed it and it is notarized. It is a kind of background check at Apple.

You submit your app to them, they scan it and check it to make sure that there is nothing suspicious, and in case all seems well, they nod their heads in silent approval.

First, you bundle up your app:

cd /path/to/your/app/
zip -r MyElectronApp.zip MyElectronApp.app

Then you send it off to Apple’s servers for review:

xcrun altool --notarize-app \
--primary-bundle-id "com.example.myapp" \
--username "your-apple-id@example.com" \
--password "your-app-specific-password" \
--file MyElectronApp.zip

That password isn’t your Apple login. It’s an app-specific password you create in your Apple ID settings. Apple won’t tell you instantly whether you passed; it takes a bit.

You can check the status like this:

xcrun altool --notarization-info <RequestUUID> \
--username "your-apple-id@example.com" \
--password "your-app-specific-password"

If all goes well, Apple gives your app a notarization ticket, basically a proof of inspection. You “staple” that ticket to your app so it always travels with it:

xcrun stapler staple /path/to/your/app/MyElectronApp.app

That last command feels almost ceremonial. After stapling, your app is truly ready to face macOS users, no more warnings, no more “unidentified developer” screens.

Test Your Application

Install your signed app on a macOS system. This is your real-world test. If everything went right, macOS will recognise your app as safe and trusted.
Open the app. No scary red warnings. No “This app can’t be opened” pop-ups. Just a clean, professional launch, the kind that instantly builds trust with users.
Run through the features. Click every button. Open every window. Push it like a real user would. You’re not just testing functionality, you’re testing confidence.

Source

Top 10 Code Signing Tools

Anna Shipman — Wed, 03 Sep 2025 10:14:30 +0000

Microsoft SignTool

If you're building for Windows, this is your starting point and likely your ending point, too. SignTool.exe is the default utility bundled with the Windows SDK. It signs .exe, .dll, .msi, and other PE files using Authenticode. It's not glamorous, but it's what everything else wraps around.

The downside? You'll need to obtain and manage a valid code signing certificate, ideally EV, if you want to avoid SmartScreen warnings and juggle a few arcane PowerShell commands. The learning curve isn't steep, but it's shaped like an old Windows dialogue functional, not forgiving.

Still, if you're targeting Windows desktops or drivers, there's no way around it. Native support and compatibility vs. poor UX and weak automation unless scripted carefully.

AWS Signer

Imagine code signing as an invisible part of your cloud automation. That's what AWS Signer offers. It integrates directly with AWS services like Lambda, EC2, and CodePipeline, and supports signing everything from apps to container images using a fully managed HSM in the background.

You don't worry about key storage, scaling, or even tool updates. It just signs, logs, and enforces policies. But it's also deeply tied to AWS. If your infra is elsewhere, this isn't your tool. Enterprise-scale signing without operational overhead, but full lock-in to the AWS ecosystem.

Apple Codesign / Xcode CLI

Apple doesn't just expect you to sign your iOS apps. They demand it. Codesign is part of a tightly locked-down ecosystem where apps must be signed, notarised, and sandboxed before the Mac or iOS even thinks about trusting them. The upside? Once signed properly, your users get a clean install experience with no security pop-ups.

Apple's codesign and xcodebuild CLI tools integrate with your provisioning profiles and developer certificates. They're powerful, but opinionated. You play by Apple's rules, or you don't play at all.

You'll spend time managing developer accounts, entitlements, and a maze of profiles, but once it's all wired together, the flow is smooth. Deep platform integration vs. zero tolerance for nonconformity or flexibility.

GPG (GNU Privacy Guard)

GPG isn't a code signing tool in the strict sense. It's a general-purpose crypto toolkit. But in the world of open-source, it's often the default way to sign code releases, Git commits, and even software archives like .tar.gz files. It's trust by Web of Trust, not by a central certificate authority.

GPG shines in transparency-first communities. If your users care more about verifiability than vendor backing, GPG signatures carry weight. They're also scriptable, lightweight, and work everywhere from Linux terminals to CI/CD workflows.

The only problem is that Key management is a DIY affair. Lose your private key and you're done. Leak it, and anyone can impersonate you. But for the security-conscious, that's part of the appeal.

JetBrains Space Automation

If you're already living inside the JetBrains world, then IntelliJ, WebStorm, and PyCharm, Space is going to trust me, it kind of feels like the next level, right? It is JetBrains' capability to incorporate DevOps: version control, CI/CD, packages and also code signing. That is its key advantage in terms of integration.

Rather than latching on to code signing at the end of your build process, Space lets you handle it like a compliance citizen. That being said, Space remains immature.

Docs are better, but they will cause you issues if you try to do something non-trivial or run-of-the-mill that falls outside of the JetBrains ecosystem. It allows Seamless Integration for JetBrains users, vs. less flexibility, and platform immaturity.

DigiCert KeyLocker

This is code signing as-a-service, designed for teams who don't want to manage private keys or hardware tokens. DigiCert KeyLocker gives you a cloud-based HSM environment with role-based access, audit trails, and automation APIs.

It's ideal for regulated industries or distributed teams where secure key access matters as much as signing speed. The downside? It's not cheap, and it's very much a managed solution. You're trusting DigiCert with your trust model.

It gives a Strong cloud HSM + managed infrastructure.

Docker Content Trust (DCT)

If you're shipping containers, you should be signing them. Docker Content Trust (DCT) uses Notary to verify that Docker images haven't been tampered with between build and deployment. It's not just a security feature. It's a sanity check in environments where your CI/CD pipeline might touch dozens of registries or environments.

The upside is integrity. The downside? It's opt-in, and enforcing it requires cultural (and tooling) discipline. But once set up, it protects one of the most vulnerable parts of the software supply chain: the container registry. Seamless for Docker-native signing and verification vs. setup friction and limited visibility outside Docker.

Azure SignTool

Signing code is one thing. Signing it securely at scale is another. Azure Key Vault, paired with Azure SignTool, is Microsoft's answer to secure, hardware-backed signing in the cloud. It's aimed at orgs that need to protect keys, enforce access policies, and sign software from a locked-down pipeline.

It's powerful but not plug-and-play. You'll need to configure identity access, integrate with Azure DevOps or GitHub, and understand a few cloud security principles. Once set up, though, it's rock solid.

KSign

When you simply have to sign a few Windows binaries and you are not interested in scripting or CLI parameters, KSign is your way to go. It is an easy GUI-based Authenticode signing wizard that is fantastic to utilise when a developer is doing work in small shops or as an individual (not simply within a broader, automation-centric pipeline).

Such simplicity is also the boundary. KSign has not been designed with DevOps or headless in mind. It is Notepad-level code signing: useful but not efficient. Simple when it comes to occasional manual signing. Automation and CI workflows are not supported.

Electron Builder

Electron Builder is not a luxury in case you develop Electron applications. It is more or less mandatory. It does it all automatically; it can package, sign the code to platforms specifically (macOS and Windows), and even notarize in case you get the whims of Apple. The signature aspect is something that does not take place as a process, but rather as a check box.

Complexity is behind that simplicity. You will still require valid certs, platform-specific setups (such as Apple Developer accounts), and CLI setups need to be configured with caution. However, when dialled in, it allows indie developers and teams to offer a much bigger punch than they could otherwise.

Reference

Top 10 Code Signing Tools for Developers

Best Code Signing Certificates

Anna Shipman — Fri, 29 Aug 2025 05:39:45 +0000

In today's digital world, trust is everything. When users download an application, they want to know it's safe, authentic, and free from tampering. That's where Code Signing Certificates come in. These certificates allow developers and software publishers to digitally sign their applications, scripts, or drivers, ensuring end-users can verify the source and integrity of the software.

But with multiple providers in the market, it can be challenging to decide which Code Signing Certificate best suits your needs. Let's explore the leading Certificate Authorities (CAs) and see what each brings to the table.

Why Code Signing Certificates Matter

Code Signing Certificates don't just add a digital signature, they create a bridge of trust. They confirm:

Authenticity - Verifies the software is from the stated publisher.
Integrity - Ensures the code hasn't been altered since it was signed.
User Trust - Removes "Unknown Publisher" warnings, improving adoption rates.

For organizations and individual developers, using a Code Signing Certificate is now more than just best practice, it's an essential step for professional distribution.

Top Providers of Code Signing Certificates

1. Comodo (Now Sectigo)

Comodo, rebranded as Sectigo, is a popular name among developers for affordable and reliable certificates. Their Code Signing Certificates work across a wide range of platforms, including Windows, Java, and mobile apps. They are especially attractive for small and mid-sized publishers thanks to competitive pricing. For developers who need extended trust, Sectigo also offers EV Code Signing Certificates, which help bypass Microsoft's SmartScreen filter more effectively.

2. SignMyCode

SignMyCode is a popular name among devs looking for cost-effective yet robust code signing certificates. Its Code Signing Certificates come with standard features like publisher identity verification, integrity protection, and removal of security warnings. What sets SignMyCode apart is its affordability without compromising essential security. For startups or small developers looking for budget-friendly solutions, SignMyCode's Code Signing Certificates are an excellent choice.

3. Sectigo

Sectigo, one of the largest CAs globally, continues Comodo's legacy with stronger branding and a wider product lineup. Sectigo's certificates integrate smoothly with most developer workflows and are recognized by all major operating systems. The company also emphasizes scalability, making it a reliable choice for enterprises managing large-scale application distributions.

4. DigiCert

DigiCert is known for premium security solutions and strong industry trust. Its Code Signing Certificates are widely adopted by enterprises that value brand reputation, strong support, and long-term reliability. DigiCert also offers EV Code Signing Certificates with stricter validation, giving an extra layer of credibility for businesses distributing sensitive or large-scale applications. If user confidence and enterprise-grade reliability are top priorities, DigiCert is hard to beat.

5. GlobalSign

GlobalSign is another leading provider that specializes in enterprise-grade certificates. Their Code Signing Certificates support multiple platforms and come with strong identity verification standards. GlobalSign is often preferred by large organizations that need centralized certificate management and strong support services. It's also an excellent choice for developers who require flexibility in both on-premises and cloud-based signing.

Choosing the Right Code Signing Certificate

When deciding which Code Signing Certificate is right for you, consider:

Budget - SignMyCode and Sectigo/Comodo provide affordable options.
Enterprise Trust - DigiCert and GlobalSign are excellent for larger organizations.
Validation Level - Standard OV Code Signing is suitable for most, but EV Code Signing is recommended for bypassing SmartScreen warnings.
Platform Needs - Ensure the provider supports all your target platforms.

Final Thoughts

Code Signing Certificates are no longer optional, they are a necessity for safe software distribution. Whether you're a solo developer or a large enterprise, choosing the right provider can significantly impact user trust and adoption rates.

Comodo/Sectigo: Affordable, reliable, widely used.
SignMyCode: Budget-friendly without compromising core security.
DigiCert: Premium choice for enterprise trust and support.
GlobalSign: Strong, enterprise-ready solutions.

By investing in the right Code Signing Certificate, you not only secure your applications but also build lasting trust with your users.

Understanding Code Repositories

Anna Shipman — Tue, 19 Aug 2025 05:40:14 +0000

What is a Code Repository?

Think of a code repository as the digital vault where your development team stores its gold, your code. Without it? You're writing on sticky notes and throwing them into the wind.

A code repository isn't just a folder where you dump your files. It's the heartbeat of your software project. It is a platform where developers store, organise, and track changes to their source code.

Whether they're in the same room or halfway across the world, it's the nucleus of your project's version control system.

You can:

Save and retrieve old versions of your code
Work in isolated branches without breaking production
Collaborate with other developers in real-time
Roll back changes when something breaks

When we discuss repositories, we primarily refer to Git, a distributed version control system that's fast, flexible, and open-source. Git lets every team member have a full copy of the project. That means you can work offline, manage changes easily, and push updates when ready.

The most widely used platform that uses git version control are GitHub, GitLab, and Bitbucket. These platforms not only store your code but also power your pull requests, CI/CD workflows, and even security scans.

Types of Code Repositories

Not all code repositories are built the same. If you want to use the right tool and secure it properly, you need to understand the two major distinctions.

Local vs. Remote Repositories

Local Repositories

These live on your machine. You're coding, committing, and tracking changes, but only you can see them. Great for solo projects, but terrible for teamwork. But the biggest risk is if your system crashes, everything goes with it.

Remote Repositories

Hosted on a server or cloud platform like GitHub, GitLab, or Bitbucket. Accessible from anywhere, anytime. Perfect for team collaboration, CI/CD workflows, backups, and more.

Remote Repositories had the upper hand because you can share your code, get feedback, track issues, and even run automated builds all from one place. Plus, no worries about lost laptops or fried hard drives.

Centralized vs Distributed Repositories

Centralized Version Control (e.g., SVN)

One central server holds the master copy. Everyone pulls from and pushes to that same server. It is easy to manage. If the server goes down? You're stuck.

Distributed Version Control (e.g., Git)

Every developer has a full copy of the repo on their local machine, including history. You can work offline, commit locally, and sync changes when ready. The benefit of it is that it gives Speed, flexibility, and fault-tolerance. But its learning curve is a little difficult, and it's not beginner-friendly.

Key Components of a Repository

Codebase (Source Code): This is the heart of your app, i.e., the code that runs your app.
Version History (Commit History): It will trace all changes, who initiated them, and when. No more guesswork.
Branches: Isolate the test environment where new features can be tested without fetching live code.
README, License, and Docs: The README describes your work. LICENSE protects it. Docs keep everyone aligned.
Integration Files of CI/CD: They automate deployments, tests, and builds, thus there is no lost time in your workflow.

Tools to Keep You Safe

GitHub Advanced Security: Detects secrets and dangerous dependencies within your repository.
GitGuardian: It checks if you have leaked secrets before or after you commit them.
Snyk: Prevents threats by detecting vulnerabilities in your code libraries and containers in real-time.
Trivy: A Low-overhead scanner to detect container and operating system security problems.
SonarQube: Scanning your code base, locating bugs, vulnerable code, and poor practices.
HashiCorp Vault: Stores your secrets outside the source code, and in a secure, centralised vault.

Reference

What is a Code Repository? Types, Best Practices and Tools for Repository Security

Digitally Signing Binaries Using the Signing Manager Controller (SMCTL)

Anna Shipman — Mon, 04 Aug 2025 08:56:02 +0000

Digitally signing binaries via a Signing Manager Controller (SMCTL) typically involves using the SMCTL command-line utility to interact with a code signing certificate and keypair managed by a certificate authority or a cloud-based key management service.

1. Sign Using the Default Signing Tool

SMCTL does this very easily by just selecting the proper signing tool according to file type and OS. If no signing tool is specified in the command, SMCTL itself decides on the best of the tools available on your system and complies with the signing operation accordingly.

This method comes out to be very comfortable for users who want secure and effective digital signatures but do not want to indulge themselves in performing the said signing tools manually.

Keypair Alias Method (Preferred)

The keypair alias method is the recommended way to sign binaries since it allows the signed binaries to be compatible with different signing tools. In general, SMCTL uses the private key associated with the given alias to carry out the signing.

This method is widely preferred because it avoids situations, on the other hand, where a user has to explicitly define a certificate fingerprint.

To sign a file using the keypair alias, the following command is given:

smctl sign --keypair-alias <keypair alias> --input <path to file>

Example:

smctl sign –keypair-alias kp3 –input C:\Users\Name\Desktop\file_to_sign.exe

This way, one could manage their certificate more easily and assure that the correct certificate is used for signing.

Certificate Fingerprint Method

If it happens that a binary must be signed with a specific certificate, the certificate fingerprint method is used.

This method is primarily used when signing with the KSP (Key Storage Provider) library, or when the certificate is already synchronized with the Windows certificate store.

To sign a file using a certificate fingerprint, use the following command:

smctl sign --fingerprint <certificate fingerprint> --input <path to file>

Example:

smctl sign –fingerprint aa42b7d92f826d0ad6d23aa0d778c8cbfab7d61d –input C:\Users\Name\Desktop\file_to_sign.exe

As the fingerprint is the unique identifier of a specific certificate, this method ensures the signing with that specific certificate. However, managing fingerprints is more cumbersome than doing so when you use the keypair alias method.

2. Sign with a Specific Third-Party Tool

Although SMCTL offers an in-built signing mechanism, situations do arise where external signing tools are warranted. In these cases, SMCTL can take care to explicitly call a third-party tool compatible with differing file formats and security policies.

Signing with an external tool is prudent if certain requirements dictate the signing process or if the default SMCTL signing tool is unavailable.

To invoke a specific third-party tool for signing, the flag –tool and the required parameters should be applied:

smctl sign --keypair-alias <keypair alias> --certificate <path to cert> --input <path> --tool <tool>

Example (using jsign):

smctl sign –keypair-alias=dynamic-kp1 –certificate C:\Users\John.Doe\Desktop\certificate.pem –input C:\Users\John.Doe\Desktop\file_to_sign.exe –tool jsign

This command explicitly instructs SMCTL to utilize jsign to carry out signing as opposed to relying on the default selection.

Such an option to choose a signing tool is especially potent in organizations due to their varied signing techniques used for different binaries by various teams.

3. Special Case: Signing Android APKs

Signing an Android package requires some special attention. Utilizing SMCTL, when signing APK files, SMCTL might generate multiple signatures for different versions of Android, and hence, sees some incompatibility bugs with some devices or app stores.

To get rid of the headaches of multiple signatures being created, Android APK files should, therefore, preferably be signed directly with Apksigner, instead of SMCTL.

Doing so will force the APK to comply with Android security policies, thus preventing installation or verification failures on devices.

Reference

How to Digitally Sign Binaries with Signing Manager Controller (SMCTL)?

DEV Community: Anna Shipman

Windows Credential Configuration for DigiCert KeyLocker & SMCTL

Prerequisites

DigiCert ONE Host Environment

DigiCert ONE API Key

DigiCert ONE Client Authentication Certificate and Password

DigiCert KeyLocker Client

Administrative Access on Windows

Steps to Set Up Credentials

1. Choose a Credential Storage Method

2. Store Credentials Using Windows Credential Manager

3. Set Up Temporary Environment Variables

4. Use a Properties File for Automated Systems

5. Why Persistent Environment Variables Are Not Recommended

6. Verify Your Configuration

Windows BSM: Tightening App Trust & Code Signing

The New Update

Introducing Secure-by-Default Execution

Code Signing will Become Mandatory

Baseline Security Mode in Microsoft 365 Environments

Characteristics:

Example Navigation Path to enable BSM (Microsoft 365)

Top Mobile App Security Solutions for 2026

AI (Artificial Intelligence) Attacks & Threats

Zero Trust Security

API Security

Rise of Mobile Malware Attacks

AI-Driven Threat Detection

Secrets Management and Managers

Meaning

Why does it matter so much?

Different Types of Secrets Managers?

Cloud-Native Secrets Managers

Managers of Third-Party Secrets.

CI/CD Platform Secrets Stores.

AWS KMS Vs Azure Key Vault Vs GCP KMS

1. Key Lifecycle Automation

AWS KMS

Azure Key Vault

GCP KMS

2. HSM (Hardware Security Module) Options

AWS KMS

Azure Key Vault

GCP KMS

3. Integration Ecosystem

AWS KMS

Azure Key Vault

GCP KMS

4. Multi-Cloud Support

AWS KMS

Azure Key Vault

GCP KMS

5. Performance & Latency

AWS KMS

Azure Key Vault

GCP KMS

6. Pricing Model

AWS KMS

Azure Key Vault

GCP KMS

7. DevOps & Automation Friendliness

AWS KMS

Azure Key Vault

GCP KMS

8. Audit Logging & Visibility

AWS KMS

Azure Key Vault

GCP KMS

9. Compliance Certifications

AWS KMS

Azure Key Vault

GCP KMS

10. Secrets and Certificate Management

AWS

Azure Key Vault

GCP

So… Which One To Use?

Configure DigiCert KeyLocker KSP Library

1. Download the DigiCert KeyLocker KSP Library

2. Register the KSP Library