Private vs Public CAs: You Might Be Using the Wrong One

To an IT team under pressure, a public Certificate Authority (CA) often looks like a hammer, and every encryption requirement looks like a nail. But using a public CA for every job is one of the most common ways to quietly break production.

What Public CAs Are Built For

A public CA (like DigiCert, Sectigo, or Let's Encrypt) is designed for one main scenario: when you need to establish trust with devices you don't control. The idea is that external users don't have to configure a thing on their end to trust your site or service.

A public CA makes sense when:

• You're running public-facing services for external users, customers, or partners with no pre-existing trust relationship with your organization
• External APIs or services connect to your infrastructure without custom client configuration
• Certificate errors would show up as a browser warning to end users
• You're signing emails and recipients need to verify the signature without any prior configuration

The CA/Browser Forum governs what public CAs can issue. You're subject to rules you don't control, which for many, is a reasonable trade-off for the scenarios above. Using a public CA may become a problem when you're using those same certificates for internal authentication.

What Private CAs Are Built For

A private CA is one you run, or one your vendor runs on your behalf. You define the issuance policy. The certificates aren't trusted anywhere by default. You push your private CA's root certificate to your devices and users through Group Policy, Intune, or your MDM platform, and your managed endpoints trust certificates issued by your private CA.

A private CA is the right fit for anything where only your own infrastructure needs to trust the certificate:

• Device authentication, proving a machine is managed and belongs to your organization
• User certificate authentication, passwordless login, smart card equivalents or internal app access
• Securing Wi-Fi (802.1X) and VPN connections
• Setting up mutual TLS (mTLS) between backend microservices
• Code signing for internal tools and scripts

You retain full control over the trust chain and issuance policy, with no dependency on external CA governance.

Public CA or Private CA? A Quick Comparison

Where Things Go Wrong

The most common mistake IT teams make is using public CA certificates for internal authentication. Public CAs were never meant for internal workloads, and two shifts happening right now are making that gap impossible to ignore.

1. No more Client Authentication EKUs on public TLS

Publicly trusted TLS certificates are no longer allowed to carry the Client Authentication EKU. Driven by CA/Browser Forum Ballot SC-081 and major root program updates, public CAs are phasing out clientAuth ahead of the March 2027 hard cutoff. If your internal device or user authentication relies on public certificates, those setups will no longer function upon your next renewal.

2. Rapidly shrinking lifespan

Public CAs are constantly cutting certificate validity windows. Under SC-081v3, public validity limits are capped at 200 days (2026), dropping to 100 days in March 2027, and 47 days by March 2029. Automated tools handle 90-day renewals fine on public web servers, but re-enrolling thousands of internal laptops or devices every six weeks is an administrative nightmare.

A private CA sits outside these constraints. Because you handle revocation directly inside your environment, you do not need artificially short lifetimes or external validation checks. You set the validity periods and rules that make sense for your team.

How to Decide Which One to Use

For each certificate in your environment, ask: do you control every device or client that needs to validate this certificate?

• If yes: Use a private CA. You push the root CA certificate, control what gets issued, and stop being subject to external rule changes.
• If no: You need a public CA. Someone connecting from outside without prior configuration needs a CA their device already trusts.

Most IT departments end up needing both: public certificates for external-facing services, private certificates for devices, users, and internal services.

How SCEPman Fits In

SCEPman is a cloud-native private CA that integrates with Microsoft Intune and Entra ID, as well as other MDM platforms through SCEP and EST. It handles automatic certificate issuance for managed devices and users.

For Intune environments, SCEPman ties certificate validity to device compliance status. A device that gets wiped or falls out of compliance loses its certificate, automatically cutting off access to Wi-Fi, VPN, and internal applications.

SCEPman can also manually issue certificates using Certificate Master. This allows IT departments to replace public CA certificates across internal systems like web portals, apps, and device management interfaces.

Where to Start

If you don't have a private CA or you're looking to move off legacy on-premises Active Directory Certificate Services (ADCS), that's a good starting point for a SCEPman conversation.

Try SCEPman for Yourself

Start a 30-day trial to see how SCEPman issues and manages private CA certificates for your devices, users, and internal services, without the overhead of running your own PKI.

Start SCEPman 30-day trial

Frequently Asked Questions