Skip to content

47-Day Certificates Are Coming. Are You Ready?

Act Now →

Enterprise applications and PKI – Part 2

Enterprise applications and PKI

In the previous article, we explored the importance of Public Key Infrastructure (PKI) from an enterprise architecture perspective. We also saw some of the typical enterprise application scenarios that need to use PKI, including public-facing websites and web applications, Virtual Private Network (VPN) services, mobile applications, and software (code signing). This article illustrates a few of the other enterprise application scenarios where PKI needs to be an integral part of enterprise architecture.

Enterprise PKI Services

Get complete end-to-end consultation support for all your PKI requirements!

Quick Answer: What Other Enterprise Scenarios Need PKI?

Beyond websites, VPNs, mobile apps, and code signing, PKI secures four more enterprise scenarios: cloud application access, internal user authentication, email through S/MIME signing and encryption, and document management through digital signatures. Each scenario replaces a weaker trust mechanism- a shared password, an unsigned document, an unverified sender- with cryptographic proof tied to a digital certificate.

Executive Summary

Enterprise architecture today has to follow a security-first approach, and PKI is central to that approach in scenarios beyond the ones covered in Part 1. This post covers four additional enterprise application scenarios that rely on PKI: cloud application access, internal user authentication, email security through S/MIME, and document management through digital signatures. It also covers a practical checklist for closing common gaps in these scenarios and how they connect to broader certificate lifecycle management.

Who Should Care About These PKI Scenarios

Extending PKI into cloud access, user authentication, email, and document workflows touches identity, security architecture, platform operations, and compliance. Here is what each role should do.

PKI Administrators

Issue and track the certificate types these scenarios need: cloud IAM certificates, user authentication certificates, S/MIME email certificates, and document-signing certificates, so certificate discovery extends past the scenarios in Part 1.

Security Architects

Extend the enterprise architectural blueprint to flag cloud applications, internal authentication, email, and document management as scenarios requiring PKI, not just the public-facing scenarios from Part 1.

Platform Teams

Integrate certificate issuance into cloud IAM, directory services, email gateways, and document management platforms so PKI enablement covers internal workflows as consistently as public-facing ones.

Compliance Teams

Confirm that cloud access, sensitive internal data, email communication, and formally signed documents are all PKI-enabled, and document any exceptions, such as unsigned contracts or password-only cloud access, as accepted risk.

CISOs

Treat unprotected internal scenarios, phishable email, unsigned documents, and password-only cloud access as measurable risk alongside the public-facing gaps covered in Part 1, and sponsor closing both sets of gaps together.

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. Cloud IAM certificates, user authentication certificates, and S/MIME email certificates all carry the same expiry risk as the public-facing certificates covered in Part 1 if they aren’t tracked under one lifecycle 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. While this schedule targets public TLS certificates directly, it signals the same direction enterprises should expect for internal certificate types, cloud access, user authentication, and email: shorter validity periods that make manual renewal impractical.

NIST finalized its post-quantum cryptography standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), on August 13, 2024. Document management and email signing certificates often protect records and communications that must remain verifiable for years, so crypto agility toward post-quantum algorithms matters as much for these internal scenarios as it does for public-facing ones.

Enterprise Cloud Applications

Cloud computing is mainstream today: research from Flexera’s RightScale State of the Cloud report has found that the large majority of organizations leverage some form of cloud technology. The benefits of cloud- elasticity, location-independent access, and usage-based pricing for infrastructure- have overcome earlier apprehensions about moving applications and data to the cloud. However, enterprises need to be as vigilant as ever to ensure appropriate identity and access management (IAM) solutions are in place for their cloud applications. PKI is one of the best IAM options for enterprise cloud applications and is much more secure than alternatives based on a username and password approach.

User Authentication

Even within the enterprise, the use of PKI is going up rapidly. Verifying the identity of enterprise users and other entities such as devices using digital certificates makes a lot of sense today, especially considering the risk of insider threats and the need to have strict access controls and audit mechanisms in place. Code signing, as explained in Part 1, requires DevOps teams and developers to sign code as part of the deployment and release cycle. PKI-based user authentication can also help restrict and monitor access to sensitive enterprise applications and data, such as personally identifiable information (PII) of customers, company IP, and trade secrets. The risk of data breach incidents where customer data is leaked or sold to the outside world by insiders can be significantly reduced by leveraging PKI-based credential management within the enterprise.

Email

For most enterprises today, email continues to be the primary communication mechanism between employees, customers, and partners. With PKI, digital certificates can be used to sign and encrypt email. More specifically, a sender uses their private key to sign an email, and uses the recipient’s public key to encrypt that email. The technology used is called Secure/Multipurpose Internet Mail Extensions (S/MIME), which is based on PKI principles, and most email providers and clients support it. Securing email communication is extremely important for addressing phishing: a recipient might get an email from somebody impersonating a known person, a colleague, customer, or partner, requesting confidential information or asking them to click a link. With PKI, the email client will alert the recipient that the sender’s identity could not be verified. Cybersecurity research consistently shows that most cyber incidents and breaches start with a simple phishing email. Beyond identity verification and the privacy of communication through encryption, non-repudiation is an additional advantage: with PKI in place, an email sender cannot later deny that they sent a particular email.

Document Management

Enterprises deal with a variety of documents that need to be formally signed by an authorized person, orders, contracts, petitions, agreements, and forms among them. Digital signatures provide a convenient way to sign these documents, since the enterprise is likely already leveraging PKI in some form. The technology behind PKI ensures that digitally signed documents carry a much higher level of security than manually signed ones. Document management applications therefore need to be able to leverage PKI and digital signatures to ensure documents are signed and timestamped as soon as they are generated, so that any unauthorized changes can be immediately and automatically detected by security tools and platforms.

In today’s world, enterprise application architecture needs to follow a “Security First” approach. For example, with cloud technology becoming mainstream, cloud security also needs to become a top priority for enterprises. Similarly, for application authentication, enterprises can no longer rely on just a username and password approach, since enterprise applications are accessed anytime and from anywhere. Threats like phishing have resulted in email security becoming a hygiene factor and not just a “good to have”. Digital signatures for documents have become the norm, replacing manual signatures.

Overall, enterprise architecture today requires application security to keep three needs in mind: stronger authentication mechanisms, validation of the device or endpoint being used to access the application, and securing the communication channel between the application and the endpoint. PKI through digital certificates provides a way for enterprises to address all three of these needs. This also means enterprises need to think about good certificate management practices, including the setup of a private certificate authority (CA) where needed, a subject covered in more depth below.

PKI Enterprise Scenarios Glossary

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

TermDefinition
Identity and Access Management (IAM)The policies and technologies used to ensure the right individuals and entities have appropriate access to enterprise resources, including cloud applications.
S/MIMESecure/Multipurpose Internet Mail Extensions, a PKI-based standard for signing and encrypting email using digital certificates.
Non-repudiationA property of digitally signed communication or documents that prevents the sender or signer from later denying they created it.
Digital SignatureA cryptographic mechanism, based on a private key, that verifies the authenticity and integrity of a document, email, or piece of code.
Private Certificate Authority (CA)A certificate authority operated internally by an enterprise to issue certificates for internal-only use cases such as user authentication and device identity.
Certificate Lifecycle Management (CLM)The process and tooling used to discover, issue, renew, and revoke certificates automatically across every PKI-enabled application and workflow.

PKI Enterprise Scenarios Issue Checklist: Impact, Action, and Owner

IssueBusiness ImpactRecommended ActionOwner
Cloud applications rely on username/password onlyWeaker IAM increases the risk of unauthorized cloud accessDeploy certificate-based authentication for cloud application accessSecurity architects, platform teams
Internal users authenticate without certificatesInsider threats and credential theft are harder to detect and containRoll out PKI-based user authentication with audit loggingPKI administrators
Email is not signed or encrypted with S/MIMEPhishing and impersonation attempts are harder for recipients to detectEnable S/MIME certificates for email signing and encryptionPKI administrators, platform teams
Documents are signed manually instead of digitallyUnauthorized changes to signed documents may go undetectedAdopt digital signatures with timestamping for document workflowsCompliance teams, platform teams
No centralized tracking across cloud, user, email, and document certificatesAn expired certificate in any scenario causes an outage or trust failureBring every PKI-enabled scenario’s certificates into one CLM programPKI administrators, compliance teams

Certificate Lifecycle Management and PKI Modernization

Every scenario in this post- cloud access, user authentication, email, and document management- 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 workflow’s certificate expires unnoticed.

Organizations extending PKI into cloud applications and internal workflows 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 cloud apps, user directories, email systems, and document platforms, and completing a PQC readiness assessment ensures these scenarios have a migration path toward crypto agility and 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. For the public-facing scenarios that complement the ones covered here, see Enterprise applications and PKI – Part 1.

Measuring Success and Ongoing Audits

Track the percentage of cloud applications requiring certificate-based IAM, the percentage of internal users authenticating with certificates rather than passwords alone, the percentage of outbound email signed or encrypted with S/MIME, and whether formally signed documents use digital signatures with timestamping. 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 scenario never silently falls back to an unprotected state.

Frequently Asked Questions

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

Beyond the public-facing scenarios in Part 1, cloud application access, internal user authentication, email, and document management also depend on PKI to replace weaker trust mechanisms with certificate-based cryptographic proof.

Why does this matter for enterprise PKI teams?

PKI teams are responsible for issuing and tracking certificate types across cloud IAM, user authentication, S/MIME email, and document signing, and for flagging any of these internal scenarios that aren’t PKI-enabled as a risk.

What risks increase if this topic is handled manually?

Manually tracking certificates across cloud applications, user accounts, email systems, and document platforms increases the risk of an expired certificate causing a login failure, an unsigned email being mistaken for phishing, or a document’s integrity being disputed.

Which teams should own this change?

Security architects extend the architectural blueprint to cover cloud, authentication, email, and document scenarios; platform teams integrate certificate issuance into each workflow; 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 scenario in this post- cloud access, user authentication, email, document management- generates certificates that need the same issuance, renewal, and revocation discipline; treating them as part of one certificate lifecycle management program prevents any single scenario from being overlooked.

How should organizations measure success?

Track the percentage of cloud applications with certificate-based IAM, the percentage of internal users authenticating with certificates, the percentage of email signed or encrypted with S/MIME, and whether formally signed documents use digital signatures.

What should be audited or monitored regularly?

Regularly audit certificate issuance and expiry dashboards across cloud, user authentication, email, and document management scenarios to catch a lapse before it causes an access failure or trust issue.

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

Enterprises running cloud applications alongside on-premises systems often need a private CA for internal-only certificates plus a public CA for external-facing needs, and both must be tracked under the same centralized certificate discovery process.

What common mistakes should teams avoid?

Common mistakes include leaving cloud application access on password-only authentication, skipping S/MIME for email, relying on manual document signatures, and tracking certificates for each scenario separately instead of under one lifecycle management program.

What should be refreshed quarterly?

Review the architectural blueprint for new cloud, authentication, email, or document workflows that should be PKI-enabled, confirm certificate validity periods against the current CA/Browser Forum schedule, and re-verify that S/MIME and document-signing certificates are still active.