Enterprise applications and PKI – Part 1

In an earlier article, we defined Public key infrastructure (PKI) as a set of roles, policies, hardware, software, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption. We also identified some of the trends in digitalization which have been driving the adoption of PKI. As the adoption of PKI increases, enterprises need to understand which of their applications need to be “PKI-enabled”. In other words, enterprise architectural blueprints should clearly identify the application scenarios to use PKI, and also flag non-conforming scenarios as potential security risks. In this article, we look at some of the typical application scenarios leveraging PKI in order to protect the enterprise and lower its risk profile.

Quick Answer: Which Enterprise Applications Need PKI?

Enterprise applications that authenticate identity or protect data in transit typically need PKI: public-facing websites and web apps (TLS certificates), VPN services (certificate-based multi-factor authentication), mobile applications (device and user validation), and software distribution (code signing). Each scenario replaces a weaker trust mechanism- passwords, unsigned downloads, and unverified connections- with cryptographic proof tied to a digital certificate.

Executive Summary

Enterprises adopting PKI need a clear map of which applications should be PKI-enabled, and which unprotected scenarios represent a security gap. This post covers four common enterprise application scenarios that rely on PKI: public-facing websites secured with TLS, VPN services using certificate-based authentication, mobile applications validated with device certificates, and software distributed with code-signed packages. It also covers a practical checklist for closing common PKI-enablement gaps and how these scenarios connect to broader certificate lifecycle management. A second post in this series, linked below, covers additional enterprise PKI scenarios.

Who Should Care About PKI-Enabling Enterprise Applications

Deciding which applications need PKI touches identity, security architecture, platform operations, and compliance. Here is what each role should do.

PKI Administrators

Issue and track the certificate types each application scenario needs: TLS, VPN client authentication, code signing, so certificate discovery covers every PKI-enabled application.

Security Architects

Build the enterprise architectural blueprint that flags which application scenarios must be PKI-enabled, and treat any non-conforming scenario, an application relying on passwords alone, as a documented risk.

Platform Teams

Integrate certificate issuance into web server, VPN, MDM, and CI/CD pipelines so PKI enablement happens consistently across every application scenario rather than one at a time.

Compliance Teams

Confirm that applications handling sensitive data or remote access are actually PKI-enabled as the architectural blueprint requires, and document any exceptions as accepted risk.

CISOs

Treat unprotected application scenarios, unsigned software, and password-only VPN access as measurable risk, and sponsor closing the gap between which applications should be PKI-enabled and which actually are.

Why This Matters: Data and Deadlines

According to DigiCert’s Trust Pulse Survey (July 2, 2025), nearly half of enterprises experienced a certificate-related outage in the past year, and 18.5% of affected organizations reported losses exceeding $250,000, with 37.5% of those incidents tied specifically to expired certificates. Every PKI-enabled application scenario in this post, TLS, VPN, code signing, inherits this same risk if its certificates aren’t tracked as part of a single lifecycle management program.

The CA/Browser Forum’s Ballot SC-081v3, approved April 11, 2025, phases maximum public TLS certificate validity down to 200 days starting March 15, 2026, 100 days starting March 15, 2027, and 47 days starting March 15, 2029. Public-facing websites and web applications, the first scenario below, are directly subject to this schedule, making manual certificate renewal increasingly impractical as validity windows shrink.

NIST finalized its post-quantum cryptography standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), on August 13, 2024. Code signing certificates in particular protect software that can stay in production for years, so any code signing infrastructure enabled today should have a path to post-quantum signature algorithms before those certificates need renewing multiple times over.

Public Facing Websites and Web Applications

The padlock symbol in the URL bar of any web browser is now a de facto requirement for any public-facing website and application. The padlock represents an SSL/TLS (Secure Sockets Layer / Transport Layer Security) encrypted connection between the browser and the website that is set up using a digital certificate being sent from the website or web application server to the browser. The certificate confirms the identity of the website or web application to the browser. How does the browser know whether the certificate itself is valid and genuine? It verifies that the certificate has not yet expired and has been issued and ‘signed’ by a trusted third party, called a Certificate Authority (CA). Once the certificate is verified, the browser sends its public key across to the server, which uses this to encrypt the data that is sent back to the browser. The browser decrypts this data using its private key. All this magic happens seamlessly in the background, courtesy of PKI.

Virtual Private Network (VPN) Services

The need to access an enterprise network remotely (for example, from a different office location or a partner location) has existed for quite some time. The typical solution for this need is a leased line – a dedicated physical line between the remote location and the enterprise network. However, the leased line approach is not feasible for individual remote workers who need to access the enterprise network, such as employees who need to work from home. This is where VPN services, with the ability to provide a secure, encrypted communication channel for access to the enterprise network over the internet, have become extremely popular.

When a remote user accesses the enterprise network through a VPN, a single authentication mechanism, for example with a username and password, is not secure enough. Multi-factor authentication (MFA) is important, with one of the authentication mechanisms being a digital certificate. The VPN channel (or ‘tunnel’) is set up only once the certificate validation is completed, as described earlier in this article.

Mobile Applications

With every member of the workforce carrying at least one mobile device (and often more than one) and distributed teams (“work from anywhere”) becoming increasingly common, Enterprise mobility is on the rise. Mobile Device Management (MDM) platforms address some of the requirements of enterprise mobility by providing the ability to provision devices, manage mobile applications, and enforce the enterprise security policy on the device. However, authentication of mobile devices and users remains a challenge. An approach solely based on username and password is just not secure enough and is not the best way to ensure user identity. Mobile device validation and encrypted communication between the device and the enterprise network, using digital certificates, is a far superior approach. Both the main mobile operating systems today, i.e., iOS and Android, offer native support for digital certificates.

Software Applications: Code Signing

Companies that need to distribute software and the associated upgrades and patches to their customers, partners, or employees usually do so today over the internet. This, however, has brought new challenges to the forefront. Earlier, software that was distributed on physical media such as compact discs (CDs) was shrink-wrapped, i.e., packaged in a box and physically sealed. Any tampering with the packaging and seal helped to alert the user. However, when the software is distributed over the internet, how does a user know whether the software (s)he is downloading is from the actual author? How does the user know that the software has not been tampered with and some malicious code or malware inserted into it?

Code signing provides the answer to these questions. Any company that wishes to distribute software over the internet uses a code signing certificate to digitally sign the software. At the client side, the browser being used for the software download and the operating system (OS) on which the software is being installed validate the code signing certificate and verify its authenticity. If the software has been tampered with, the user is alerted immediately. Without code signing, depending on the browser security settings, the user might get an alert, or the software may not get downloaded at all. If the user ignores the warning, downloads the software and attempts to install it, (s)he gets another warning, this time from the OS, that the publisher of the software could not be verified. As a result of these warnings, users may choose to abort the download, or abort the installation of the software – which is why it is important for companies to ensure that they sign the software that they publish.

These are some of the enterprise application scenarios that need to use PKI. There are a few others, covered in Enterprise applications and PKI – Part 2.

PKI Enablement Glossary

Quick, extractable definitions for the terms used throughout this post.

Term	Definition
Public Key Infrastructure (PKI)	The roles, policies, hardware, software, and procedures used to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption.
TLS/SSL Certificate	A digital certificate that lets a browser verify a website’s identity and establish an encrypted connection.
Certificate Authority (CA)	A trusted third party that issues and signs digital certificates, confirming the identity of the certificate holder.
Multi-Factor Authentication (MFA)	An authentication approach combining more than one verification mechanism, such as a password and a digital certificate, to confirm identity.
Code Signing Certificate	A certificate used to digitally sign software, letting a browser or OS verify the publisher’s identity and confirm the software hasn’t been tampered with.
Certificate Lifecycle Management (CLM)	The process and tooling used to discover, issue, renew, and revoke certificates automatically across every PKI-enabled application.

PKI Enablement Issue Checklist: Impact, Action, and Owner

Issue	Business Impact	Recommended Action	Owner
Public website or web app missing valid TLS	Browsers flag the site as untrusted, damaging user trust and blocking access	Issue and automate renewal of TLS certificates for every public-facing application	PKI administrators, platform teams
VPN access relies on password only, no certificate-based MFA	A stolen password alone grants remote network access	Add certificate-based authentication as a required VPN MFA factor	Security architects
Mobile devices authenticate with username/password only	Weak authentication makes device or user impersonation easier	Deploy device certificates via MDM for mobile authentication	Platform teams
Software distributed without code signing	Users see publisher-unverified warnings or block the download entirely	Sign all distributed software and patches with a code signing certificate	Security architects, platform teams
No centralized tracking across TLS, VPN, and code signing certificates	An expired certificate in any scenario causes an outage or trust warning	Bring every PKI-enabled application’s certificates into one CLM program	PKI administrators, compliance teams

Certificate Lifecycle Management and PKI Modernization

Every application scenario in this post- public websites, VPN, mobile, code signing- depends on certificates that need the same discovery, issuance, and renewal discipline as any other part of a PKI modernization program. CertSecure Manager automates certificate discovery, issuance, and renewal across all of these scenarios so no PKI-enabled application’s certificate expires unnoticed.

Organizations scaling PKI across many application scenarios without operating that infrastructure entirely in-house can rely on PKI-as-a-Service for a managed, cloud-hosted certificate authority. Building a machine identity inventory through CBOM Secure helps surface every certificate already in use across websites, VPNs, mobile devices, and signed software, and completing a PQC readiness assessment ensures these application scenarios have a migration path to post-quantum algorithms. Encryption Consulting’s PQC Center of Excellence provides guidance on sequencing that migration.

For more on why certificate automation matters across the environment, see our Education Center articles on the stages in a certificate’s lifecycle and how to avoid certificate outages. Continue reading in Enterprise applications and PKI – Part 2 for additional application scenarios.

Measuring Success and Ongoing Audits

Track the percentage of public-facing applications with valid, automatically renewed TLS certificates, the percentage of VPN access requiring certificate-based MFA, and whether every piece of distributed software is code signed. Audit certificate issuance logs and expiry dashboards across all four scenarios on a recurring basis, quarterly for policy-driven factors like the CA/Browser Forum validity schedule, and continuously for certificate expiry, so a PKI-enabled application never silently falls back to an unprotected state..

Frequently Asked Questions

What is the main takeaway from Enterprise applications and PKI – Part 1?

Public-facing websites, VPN services, mobile applications, and software distribution all rely on PKI to replace weaker trust mechanisms with certificate-based cryptographic proof, and enterprises need an architectural blueprint identifying which applications must be PKI-enabled.

Why does this matter for enterprise PKI teams?

PKI teams are responsible for issuing and tracking the different certificate types, TLS, VPN client authentication, and code signing that each application scenario requires, and for flagging any application that isn’t PKI-enabled as a risk.

What risks increase if this topic is handled manually?

Manually tracking certificates across websites, VPNs, mobile devices, and signed software increases the risk of an expired TLS certificate breaking a public site, or a code signing certificate lapsing mid-release.

Which teams should own this change?

Security architects build the architectural blueprint identifying which applications need PKI, platform teams integrate certificate issuance into each application scenario, PKI administrators track certificates across all of them, and compliance teams verify the blueprint is actually followed.

How does this connect to certificate lifecycle management?

Every PKI-enabled application scenario- TLS, VPN, mobile, code signing- generates certificates that need the same issuance, renewal, and revocation discipline; treating them all as part of one certificate lifecycle management program prevents any single scenario from being overlooked.

How should organizations measure success?

Track the percentage of public-facing applications with valid automated TLS, the percentage of VPN access requiring certificate-based MFA, and whether all distributed software is code signed.

What should be audited or monitored regularly?

Regularly audit certificate issuance and expiry dashboards across all PKI-enabled application scenarios to catch a lapse before it causes a trust warning or outage.

How does this topic affect cloud, hybrid, or multi-CA PKI?

Enterprises using multiple CAs across cloud and on-premises environments need centralized certificate discovery spanning every application scenario, since a certificate issued by an untracked CA is just as likely to expire unnoticed as one from a tracked CA.

What common mistakes should teams avoid?

Common mistakes include leaving VPN access on password-only authentication, distributing software without code signing, and tracking certificates for each application scenario separately instead of under one lifecycle management program.

What should be refreshed quarterly?

Review the architectural blueprint for new application scenarios that should be PKI-enabled, confirm TLS certificates meet the current CA/Browser Forum validity schedule, and re-verify VPN and mobile authentication still require certificates.