A private CA operates independently from the public PKI trust chain - it's not included in browser or operating system root certificate stores. This means you control the entire certificate hierarchy: root CA, intermediate CAs, and certificate policies.

Technically, private CAs use the same cryptographic standards (X.509, RSA/ECC key pairs, standard extensions) as public CAs, but you define the validation rules, naming conventions, and validity periods without external oversight. To use certificates from your private CA, you must distribute and trust the root certificate on all devices and systems that need to validate them. This gives you complete autonomy but requires internal trust distribution infrastructure.

Yes, most organisations run hybrid PKI environments. Public certificates secure internet-facing services (websites, APIs, customer portals) where browser trust is required and S/MIME certificates might be used to secure the email traffic. Private certificates secure internal resources (internal applications, device authentication, employee VPN access, inter-service communication).

Your certificate management platform should handle both certificate types, allowing you to apply different policies and lifecycles based on the use case. Just ensure your systems are configured to trust your private Root CA for internal certificates while maintaining trust in public Root CAs for external communication.

A compromised private root CA is a critical security event requiring immediate response. You must:

• Revoke all certificates issued by that CA (effectively breaking authentication across your infrastructure)

• Generate a new root CA with fresh key material

• Re-issue all certificates from the new CA

• Redistribute the new root certificate to all systems and devices

Private CA key protection is paramount:

• Store root CA keys in Hardware Security Modules (HSMs)

• Implement strict access controls with multi-person authorisation

• Maintain offline backups of root keys in secure locations

• Use intermediate CAs for day-to-day certificate issuance (so the root key isn't used frequently)

SwissSign's Managed Private PKI handles these security controls, reducing your risk of compromise compared to self-operated infrastructure.

A SwissSign provided Private Managed PKI uses the same revocation mechanisms as public PKI: Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP). When you revoke a certificate, the CA publishes updated CRLs and responds to OCSP queries indicating the certificate's revoked status.

Your applications and systems must be configured to check revocation status - this isn't always enabled by default for private certificates. Best practice: implement OCSP stapling where possible (servers provide revocation status directly) and monitor which systems are actually checking revocation. With SwissSign Managed Private PKI, the revocation infrastructure is operated as part of the service.

Operate your own internal PKI only if you have:

• Specific regulatory requirements mandating on-premises CA infrastructure

• Sufficient IT security expertise to properly configure and secure CA systems

• Dedicated staff for ongoing CA operations and security updates

• The budget for HSMs, redundant infrastructure, and disaster recovery

Most organisations underestimate these requirements.

Managed Private PKI gives you the same control over certificate policies and issuance while outsourcing the operational burden. You maintain control over who gets certificates, certificate naming and extensions, validity periods, and revocation - but SwissSign operates the CA infrastructure, handles security updates, manages HSMs, ensures high availability, and maintains audit compliance. Unless you have compelling reasons to run your own CA, managed services reduce risk and cost.

Unlike public certificates (limited to 398 days for TLS, soon to be even shorter), private certificates can have any validity period you define. Common approaches:

• 1-2 years for user certificates to balance security and convenience

• 3-5 years for device certificates where replacement is difficult

• 10+ years for root and intermediate CA certificates

• 90 days or less for automated high-security environments where short-lived certificates reduce revocation complexity

Your validity period should match your operational capabilities - if you can't reliably renew device certificates every year, issue 5-year certificates. If you have full automation via a Certificate Lifecycle Management solution, 90-day certificates provide better security. SwissSign Private PKI supports flexible validity periods, letting you optimise for each use case rather than forcing one policy across all certificate types.

Private PKI integrates with IAM systems through several mechanisms. For user certificates, integration with Active Directory or LDAP allows automatic certificate enrollment tied to user accounts - when a user authenticates to AD, they can automatically receive a certificate for email signing or VPN access. For device certificates, integration with MDM (Mobile Device Management) or device provisioning systems enables automatic certificate deployment during device enrollment.

API-based integration allows your IAM system to request certificates programmatically based on role changes or access requests. SCEP (Simple Certificate Enrollment Protocol) provides standardised device enrollment. The key is that SwissSign Private PKI provides the certificate issuance capabilities while your IAM system controls the policies about who or what receives certificates.

This depends on how your private PKI is structured. Best practice: maintain ownership of your root CA certificate and private key, even in a managed service model. SwissSign can generate and secure an intermediate CA under your root, so certificates chain to your organisation's root. If you switch providers, you take your root CA and create new intermediates with the new provider - existing certificates remain valid until expiration.

Alternative: SwissSign operates the complete CA hierarchy as a service. In this model, migration requires re-issuing all certificates from a new CA (either a new managed service or your own infrastructure). Before committing to a managed private PKI, clarify the root CA ownership model and ensure you have an exit strategy that doesn't require immediate re-issuance of all certificates.

Yes, comprehensive audit logging is standard for private PKI services. SwissSign Private PKI provides audit trails showing:

• Every certificate request and who authorised it

• Certificate issuance with timestamps and requester identity

• Certificate revocations and the reason codes

• Administrative actions like policy changes or CA configuration updates

• API access logs for programmatic certificate management

These logs support compliance requirements for regulations like DORA, NIS2, and industry-specific standards requiring certificate accountability. You can export audit logs for integration with your SIEM (Security Information and Event Management) system. For regulated industries, this audit capability is often a primary reason to use managed PKI over self-service certificate tools that lack comprehensive logging.