Quick answer: A self-signed certificate is a digital certificate signed by its own creator instead of a trusted Certificate Authority (CA). It works for internal tools, development environments, and short-lived test systems, but browsers, code signing platforms, and compliance frameworks reject it for anything customer-facing, which makes CA-issued certificates the only safe choice in production.

Every TLS handshake, every signed executable, and every internal admin dashboard depends on a certificate that something else trusts. When you self-sign a certificate, you are the one vouching for yourself, which works fine until a browser, an auditor, or a customer needs proof that isn’t yours to give. This guide covers which certificate types are safe to self-sign, when self-signing turns into a liability, and how PKI, security, platform, and compliance teams should govern the practice going forward.

Key Takeaways

Self-signed certificates are appropriate only in isolated, non-production settings: development, testing, internal tools, and short-lived demos.
External-facing services and code signing should never use self-signed certificates. Browsers and operating systems reject or flag them outright.
DigiCert’s 2025 Trust Pulse Survey found that 45% of enterprises experienced certificate-related downtime in the past year, and 37.5% of those outages traced back to expired certificates.
The CA/Browser Forum’s Ballot SC-081v3 is cutting public TLS certificate lifespans to 200 days by March 2026, 100 days by March 2027, and 47 days by March 2029, which makes manual tracking of any certificate, self-signed or CA-issued, increasingly unworkable.
PKI, security, platform, and compliance teams each own a piece of self-signed certificate governance, and tools like CertSecure Manager and CBOM Secure give them shared visibility into where these certificates actually live.

What Is a Self-Signed Certificate?

A self-signed certificate is a digital certificate in which the issuer and the subject are the same entity. In other words, you are vouching for yourself. There is no third-party Certificate Authority involved to validate your identity or confirm that your certificate can be trusted. Self-signed certificates can be useful in internal networks and development phases, but they pose significant risks when not properly managed. Security teams often lack visibility into their usage, location, and ownership, which makes it difficult to detect compromise or revoke them after a breach.

Without validation from a CA and proper PKI hygiene, including secure key storage, self-signed certificates can become serious vulnerabilities, especially in production environments. Mismanagement increases the risk of spoofing and exploitation, which is why certificate discovery across every environment, not just production, is the first real control most organizations are missing.

What Types of Certificates You Can Self-Sign

While self-signed certificates often raise red flags, there are a few scenarios where they are practical, provided they are used with caution and proper oversight.

Development and Testing Environments

In isolated dev and test setups, self-signed certificates are a quick, cost-free way to simulate secure connections. They let developers test SSL/TLS functionality without needing a CA. These certificates should never make their way into production, though, and even in test environments, it is important to track and manage them to avoid accidental misuse.

Internal Use and Temporary Projects

Not every certificate needs to be publicly trusted, especially when the work is happening behind the scenes. In controlled environments, self-signed certificates can be a practical solution for internal tools and short-term projects.

For example, internal applications like intranet portals or admin dashboards accessed only by authorized users may not require CA validation. In these cases, the absence of a trusted signature has minimal impact, provided the environment is secure and access is restricted. Even internally, though, it is worth considering an internal private PKI for better oversight and scalability as the number of certificates grows.

Similarly, spinning up a quick internal demo or a short-lived app for a limited audience is a fast, cost-effective way to enable secure connections with a self-signed certificate. Convenience should not come at the cost of security, though. These certificates still need to be tracked, managed, and decommissioned properly to avoid lingering vulnerabilities.

When You Should Not Use Self-Signed Certificates

While self-signed certificates have their place, there are several critical use cases where they simply do not belong. Here is where you should always opt for CA-issued certificates instead.

External-Facing Services

When your digital services are exposed to the outside world, whether through a public website, a customer-facing app, or an external API, trust is everything, and self-signed certificates simply do not deliver it.

Browsers and client applications are built to reject or warn against self-signed certificates. If your website or app uses one, users are greeted with alarming security alerts like “Your connection is not private.” These warnings disrupt the user experience and erode trust in your brand. In many cases, users abandon the session altogether.

Beyond the optics, there is a real security risk. Without validation from a trusted CA, self-signed certificates are vulnerable to spoofing and man-in-the-middle attacks, and if users bypass the warning, they may unknowingly expose sensitive data.

Code Signing

When distributing software, a code signing certificate proves your code is authentic and untampered. Self-signed certificates do not offer this assurance and are typically rejected by operating systems and app stores. Users see warnings that your software is from an unknown source, which is hardly reassuring to anyone downloading it.

Why Self-Signed Certificates Are Risky in Production

Self-signed certificates are convenient, but they come with a long list of risks, especially when used in production environments.

Not Trusted by Default

Browsers, operating systems, and most applications do not trust self-signed certificates by default. That is why you see those “Your connection is not private” warnings when visiting a site with a self-signed cert. It is not just an annoyance. It is a red flag for users and a potential trust-breaker for your brand.

No Revocation Mechanism

With CA-issued certificates, you can revoke them if the private key is compromised. Self-signed certificates do not have a built-in revocation mechanism like CRLs (Certificate Revocation Lists) or OCSP (Online Certificate Status Protocol). If something goes wrong, you are stuck waiting it out or manually pulling the certificate everywhere it was deployed.

Poor Visibility and Management

Self-signed certificates often fly under the radar. They are rarely tracked in centralized systems, which means they can expire without warning or be forgotten entirely. This opens the door to outages or, worse, security breaches, and the numbers back this up.

DigiCert’s Trust Pulse Survey, published July 2, 2025, found that 45% of enterprises reported certificate-related downtime in the past year, and 37.5% of those outages were caused specifically by expired certificates. The same survey found that 31% of affected organizations lost between $50,000 and $250,000 from certificate-related incidents, and another 18.5% lost more than $250,000 (Source: DigiCert). Those losses scale quickly once self-signed certificates start multiplying, undocumented, across dev, staging, and internal systems.

Compliance and Audit Issues

Many regulatory frameworks, including PCI DSS, HIPAA, and SOC 2, require the use of certificates issued by trusted CAs. Using self-signed certificates in production can put your organization out of compliance and at risk of audit findings or penalties. An undocumented self-signed certificate discovered mid-audit is one of the more preventable findings a compliance team will ever have to explain.

Certificate Automation and the 47-Day TLS Countdown

On April 11, 2025, the CA/Browser Forum passed Ballot SC-081v3, a measure proposed by Apple and endorsed by Sectigo, cutting the maximum validity of public TLS certificates from 398 days down to 47 days on a phased schedule: 200 days starting March 15, 2026, 100 days starting March 15, 2027, and 47 days starting March 15, 2029 (Source: Sectigo). This applies to publicly trusted TLS certificates, not self-signed ones directly, but the operational pressure it creates touches both.

Once public certificates renew every 47 days instead of once a year, any team still tracking certificates in a spreadsheet, self-signed or CA-issued, runs out of road. 47-day TLS certificate readiness and self-signed certificate governance end up requiring the same fix: a central inventory and automated certificate automation workflow that issues, rotates, and retires certificates without a person remembering an expiration date.

Multi-Cloud and Hybrid PKI Environments

Multi-cloud and hybrid PKI setups multiply the places a self-signed certificate can quietly appear: a load balancer in one cloud, an internal API gateway in another, an on-premises admin console nobody has touched in a year. Each environment tends to generate its own certificates through its own tooling, which is how sprawl happens in the first place.

The fix is not banning self-signed certificates outright. It is applying one discovery and policy layer across every environment, so a self-signed certificate on an AWS load balancer and one inside an on-premises data center show up in the same inventory, under the same rules. This is also where crypto agility and PQC readiness planning start to overlap with everyday certificate hygiene: an environment that cannot see all of its certificates today will not be able to migrate them to post-quantum algorithms later, and a living CBOM is what turns that discovery into an actual, trackable plan.

Best Practices for Using Self-Signed Certificates

If you decide to use self-signed certificates, here are a few ways to do it safely.

Use strong cryptography: Stick with RSA 2048 or higher, or ECC, and use SHA-256 or better for hashing.
Set short expiry periods: Do not let self-signed certificates live indefinitely. Rotate them on a regular schedule.
Secure the private key: Store it in a secure location with strict access controls.
Track and monitor: Maintain an inventory of every self-signed certificate and monitor expiration dates continuously, not just at renewal time.

Decision Guide: Use Case, Recommendation, and Ownership

Use this table to decide whether a certificate belongs on a self-signed path or a CA-issued one, and who should own that decision.

Use Case	Recommendation	Operational Owner	Expected Outcome
Development or test environment	Self-sign with a short expiry and automatic rotation	Platform team	Fast iteration without exposing production-level trust
Internal admin tool or intranet portal	Self-sign only within a governed internal PKI	PKI team	Controlled trust without public CA cost
Public website or external API	Use a CA-issued certificate	Security team	No browser warnings; customer trust maintained
Software or firmware distribution	Use a CA-issued code signing certificate	Security team	Passes OS and app-store validation checks
Regulated workload (PCI DSS, HIPAA, SOC 2 scope)	Use a CA-issued certificate, documented in the CBOM	Compliance team	Audit-ready evidence with no compliance findings
Existing self-signed certificate found in production	Discover it, inventory it, and migrate to CA issuance	PKI and security teams	Removes hidden expiration and outage risk

How Can Encryption Consulting Help?

Encryption Consulting’s certificate management solution, CertSecure Manager, is a comprehensive platform for digital certificate management across your environment.

You can use CertSecure Manager’s built-in certificate discovery feature to identify high-risk certificates, including self-signed and wildcard certificates, across network endpoints and certificate stores. It also surfaces self-signed certificates issued by your internal or public CAs through its certificate inventory and high-risk reporting tools.

Use Encryption Consulting’s PKI-as-a-Service to simplify PKI deployment with end-to-end certificate issuance, automated lifecycle management, policy enforcement, and compliance alignment, removing the need to lean on self-signed certificates in the first place. For organizations that need a live, continuously updated view of every certificate and cryptographic asset they own, CBOM Secure extends that same discovery into a full cryptographic bill of materials, and the PQC Center of Excellence is a good next stop for teams that also need to plan their post-quantum migration.

Additionally, Encryption Consulting’s advisory services can help your organization build enterprise-grade data protection strategies that strengthen compliance, close risk blind spots, and align security with business objectives across cloud, on-premises, and hybrid environments.

For more on CertSecure Manager, visit CertSecure Manager.
For more on PKI-as-a-Service, visit PKI-as-a-Service | Managed PKI | Encryption Consulting.
For more on our products and services, visit Encryption Advisory Services or Encryption Consulting.

Conclusion

Just because you can self-sign a certificate does not mean you should. Self-signed certificates are fine in controlled environments or for internal use, but for anything public-facing or mission-critical, the risks outweigh the convenience. As public TLS lifespans shrink toward 47 days and cryptographic estates grow more distributed, trust is best established through a reputable CA and tracked through a certificate inventory that never goes stale.

Frequently Asked Questions

What is the main takeaway from types of certificates you can self-sign and the risks of doing so?

Self-signed certificates are safe only for internal, non-production use, such as development, testing, and isolated internal tools. Once a certificate reaches an external-facing service, code signing, or a regulated environment, it needs to come from a trusted Certificate Authority. Treat every self-signed certificate as inventory to track, not a shortcut to forget about.

Why does this matter for enterprise certificate lifecycle management?

Self-signed certificates are among the easiest assets to lose track of because they rarely move through a central issuance workflow. Without lifecycle management, they expire silently, outlive their intended use, and create exactly the kind of undocumented trust relationships that lead to outages and failed audits.

What teams are responsible for acting on this guidance?

PKI teams set policy for where self-signing is permitted and enforce short validity periods. Security teams discover and monitor certificates across the environment. Platform teams handle day-to-day issuance and rotation for dev and internal tools. Compliance teams confirm no self-signed certificate sits inside a regulated, customer-facing scope.

What risks increase if this topic is handled manually?

Manual tracking misses certificates the moment they are created outside a formal request process, which is exactly how most self-signed certificates come into existence. That gap leads to unexpected expirations, outages, and certificates that surface during an audit with no documented owner or business justification.

How does automation reduce certificate outage risk?

Automated certificate lifecycle management issues, renews, and revokes certificates on a set schedule instead of relying on someone remembering an expiration date. It also gives security teams a single inventory to check, so a self-signed certificate quietly running in production gets flagged and replaced before it causes downtime.

What metrics should teams track after implementation?

Track the number of self-signed certificates discovered outside approved use cases, average time to remediate a flagged certificate, the percentage of certificates under automated renewal, and certificate-related downtime incidents per quarter. A falling count of unmanaged self-signed certificates is the clearest sign the program is working.

How does this connect to 47-day TLS certificate readiness?

The CA/Browser Forum’s Ballot SC-081v3 cuts public TLS certificate validity to 200 days by March 2026, 100 days by March 2027, and 47 days by March 2029. Manual processes that already struggle with untracked self-signed certificates will not survive renewal cycles that short, which makes automation a prerequisite rather than an upgrade.

How should this be handled in multi-cloud or hybrid PKI environments?

Multi-cloud and hybrid environments multiply the places a self-signed certificate can appear: a load balancer in one cloud, an internal API gateway in another, an on-premises admin console. Centralized certificate discovery and one consistent issuance policy across every environment are what keep that sprawl from turning into an unmanaged risk.

Types of Certificates You Can Self-Sign and the Risks of Doing So