Private PKI for Machine-to-Machine Identity in Hybrid Environments

Every service-to-service call in a modern enterprise infrastructure is a potential identity problem. When a payment service calls an order management API, when a Kubernetes pod requests data from an internal database, when an edge device sends telemetry to a cloud aggregation service, the receiving system has no inherent way to verify that the caller is who it claims to be unless the caller can prove its identity with a credential the receiver trusts. In most enterprise environments, this identity verification is either absent (internal network location is treated as implicit trust) or implemented with shared secrets (API keys and service account tokens that can be stolen, rotated inconsistently, and are difficult to revoke instantly at scale).

Private PKI solves the machine identity problem the same way it solves the user identity problem: every machine entity receives a certificate from a trusted CA, presents that certificate when initiating connections, and is validated or rejected based on whether the certificate is valid, unrevoked, and issued by a trusted authority. PKI as a Service makes this feasible at hybrid enterprise scale: a single governed CA hierarchy issues certificates for services running on-premises, in cloud environments, in Kubernetes clusters, and on edge devices, with consistent policy, automated enrollment, and CLM-level visibility across the entire machine certificate estate.

Quick Answer: How Does Private PKI Enable Machine-to-Machine Identity?

Private PKI enables M2M identity by issuing a certificate to every machine entity that needs to authenticate: services, pods, VMs, containers, APIs, network appliances, and edge devices. When one machine initiates a connection to another, it presents its certificate; the receiving machine validates the certificate chain against the trusted private CA and decides whether to accept the connection. This is mutual TLS (mTLS), and it provides cryptographic identity verification for every service-to-service call without shared secrets, without a central authentication endpoint that all calls must route through, and with revocation that takes effect within seconds of a compromise being detected.

Key Takeaways

• Machine identity sprawl is the primary risk in hybrid infrastructure. Internal certificates accumulate across teams, cloud accounts, Kubernetes clusters, and edge environments without central inventory or policy enforcement. A private PKIaaS CA with CLM integration provides the visibility layer that makes the machine certificate estate governable: every certificate issued is logged, every expiry monitored, every revocation recorded.
• mTLS (mutual TLS) is the correct authentication mechanism for service-to-service communication because it authenticates both the server and the client at the TLS layer, before any application-level request is processed. A service without a valid certificate from the trusted CA cannot establish an mTLS connection to a protected service, regardless of whether it has network access to that service’s endpoint.
• SPIFFE (Secure Production Identity Framework for Everyone) is the open standard for workload identity in cloud-native environments. SPIFFE SVIDs are X.509 certificates with URI SANs encoding the workload’s SPIFFE ID. PKIaaS can serve as the upstream CA authority for SPIRE-based SPIFFE deployments, anchoring ephemeral workload certificates to the organization’s governed CA trust hierarchy.
• cert-manager is the Kubernetes-native certificate provisioning controller that connects Kubernetes workloads to the PKIaaS CA. The platform team configures a cert-manager ClusterIssuer pointing at the PKIaaS ACME or CA Gateway endpoint; services declare Certificate resources in their manifests; cert-manager handles issuance, delivery to Kubernetes Secrets, and automatic renewal without human interaction.
• PKIaaS supports multiple enrollment protocols for different machine environments: ACME for cloud-native and Linux services, EST for enterprise servers and network appliances, CMP for embedded and edge devices, and SCEP for network devices and MDM-enrolled machines. A single PKIaaS CA management plane governs all certificate issuance regardless of which enrollment protocol the machine uses.

Why Shared Secrets Fail for Machine Identity at Scale

The default approach to machine identity in most enterprise environments is shared secrets: API keys assigned to service accounts, long-lived tokens stored in environment variables or configuration files, database passwords embedded in connection strings, and service account credentials that rotate on a slow schedule or not at all. These approaches have compounding problems as the machine estate grows:

• No cryptographic binding to the machine: An API key or service account token is a bearer credential: anyone who possesses it can use it, from any machine, on any network. There is no cryptographic proof that the caller using the credential is the specific machine or service it claims to be. A leaked API key from a compromised environment file gives the attacker the same access as the legitimate service;
• Rotation complexity at scale: Rotating a shared secret requires updating it in every location where it is configured: every environment variable, every Kubernetes Secret, every CI/CD pipeline configuration, every infrastructure-as-code module that references it. At scale, rotation events become operational incidents that are skipped or done incompletely, leaving long-lived credentials in production indefinitely;
• No instant revocation path: When a machine is compromised, revoking access requires knowing every credential that machine held and invalidating each one at every service that accepted it. With PKI certificates, revoking the certificate revokes access to every service that validates against the PKIaaS CA’s OCSP responder in a single operation;
• No unified inventory: Shared secrets accumulate in different credential stores, configuration management systems, and cloud secrets managers without a unified view of which service has which credential and when it was last rotated. Machine certificate inventory in a CLM platform connected to the PKIaaS CA provides a unified view of every certificate across all machine environments.

Mutual TLS: The Authentication Layer for M2M Communication

Mutual TLS (mTLS) extends standard TLS by requiring both the server and the client to present certificates during the TLS handshake. In a service mesh or internal API architecture using mTLS:

• Service A initiates a connection to Service B’s HTTPS endpoint;
• Service B presents its server certificate; Service A validates it against the trusted CA chain;
• Service B requests a client certificate from Service A; Service A presents its client certificate;
• Service B validates Service A’s certificate against the trusted CA chain and checks revocation via OCSP;
• If both certificates are valid, the mTLS session is established and application data flows;
• If either certificate is invalid or revoked, the TLS handshake fails and no application data is exchanged.

The critical property of mTLS for machine identity is that authentication happens before any application-level processing. A compromised internal machine that attempts to call a protected service cannot craft a valid certificate from the organization’s private CA. A network-level attacker on the internal network who intercepts traffic cannot inject requests into an mTLS-protected service call because they cannot produce a valid client certificate. The private CA’s trust hierarchy defines the boundary of what is trusted; any machine not issued a certificate by that CA is outside the trust boundary regardless of its network location.

For the PKIaaS CA, mTLS machine certificates use the TLS Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2) and, for services that also accept inbound connections, the TLS Server Authentication EKU (OID 1.3.6.1.5.5.7.3.1). The certificate’s Subject CN or URI SAN identifies the service, following the organization’s naming convention (typically the service’s DNS name, SPIFFE ID, or Kubernetes service FQDN). Certificate validity for machine mTLS certificates is typically short: 24 hours to 90 days, with automated renewal handled by the service’s certificate management agent before expiry.

SPIFFE Workload Identity and PKIaaS

SPIFFE (Secure Production Identity Framework for Everyone) is an open standard maintained by the Cloud Native Computing Foundation (CNCF) that defines a uniform identity framework for workloads across heterogeneous infrastructure. SPIFFE defines:

• The SPIFFE ID: A URI-format identity in the form spiffe://trust-domain/path/to/workload, where trust-domain corresponds to the organization’s administrative domain and the path identifies the specific workload. For example, spiffe://example.com/env/production/service/payment-api identifies the payment API service in the production environment;
• The SVID (SPIFFE Verifiable Identity Document): An X.509 certificate with the SPIFFE ID encoded as a URI SAN. The SVID is what workloads present in mTLS connections; the receiving service validates the SVID’s SPIFFE ID against its authorization policy to determine whether the calling workload is permitted to make the request;
• The Workload API: A local Unix domain socket API through which workloads retrieve their SVIDs without needing to manage certificate storage themselves. The SPIFFE runtime (SPIRE) delivers fresh SVIDs to workloads before their current SVIDs expire, handling certificate rotation transparently.

SPIRE is the reference implementation of the SPIFFE standard. In a PKIaaS integration, SPIRE is configured with an upstream CA plugin that requests intermediate CA certificates from the PKIaaS CA. SPIRE uses these intermediate CA certificates to sign SVIDs for the workloads it serves. The SVIDs chain to the organization’s PKIaaS root CA, providing a single unified trust anchor for SPIFFE-identified workloads alongside non-SPIFFE machine certificates issued directly by the PKIaaS CA. The CLM platform connected to PKIaaS can inventory the intermediate CA certificates issued to SPIRE, even though the individual short-lived SVIDs issued by SPIRE from those intermediate CAs are too short-lived for traditional CLM inventory to track directly.

Machine Identity in Kubernetes with cert-manager and PKIaaS

Kubernetes is the most common environment for machine-to-machine communication in cloud-native hybrid architectures. Services in a Kubernetes cluster communicate through the cluster’s DNS and service layer; when mTLS is applied, each service needs a certificate identifying it to the other services it communicates with.

cert-manager for Service Certificate Provisioning

cert-manager provisions machine identity certificates for Kubernetes services by connecting the cluster to the PKIaaS CA. The platform team configures a ClusterIssuer (or namespace-scoped Issuers for multi-tenant clusters) that points at the PKIaaS ACME endpoint or CA Gateway API. Services declare Certificate resources specifying the desired subject, SANs (DNS SANs for the service’s Kubernetes service FQDN, and optionally a URI SAN with the service’s SPIFFE ID), validity period, and renewal threshold. cert-manager submits the certificate request to the PKIaaS CA, stores the issued certificate as a Kubernetes Secret, and mounts it into the service’s pods via a volume mount or projected secret. The service reads its certificate and private key from the mounted path and presents them in mTLS connections to other services.

cert-manager’s automatic renewal means machine certificates in Kubernetes are always fresh. If the PKIaaS CA’s certificate profile is updated (for example, to enforce a shorter validity period as part of a security improvement), the next renewal request under the updated profile produces a certificate with the new parameters. The service does not need to be redeployed; cert-manager triggers the renewal and updates the Kubernetes Secret, and the service picks up the new certificate on the next file system sync.

Service Mesh Certificate Integration

Service meshes (Istio, Linkerd, and others) provide automatic mTLS between all services in a mesh without requiring individual services to implement TLS themselves. The service mesh’s data plane (Envoy proxy sidecars in the case of Istio) handles the mTLS handshake on behalf of the application; the application communicates with its sidecar over a local plaintext connection and the sidecar handles all mTLS connections to other services.

By default, service meshes use an internal, self-signed CA to issue certificates to data plane proxies. This internal CA is not integrated with the organization’s PKIaaS CA hierarchy, meaning service mesh certificates are invisible to the CLM platform, not governed by the same profiles and policies as other machine certificates, and not revocable through the PKIaaS revocation mechanism. Integrating the service mesh with PKIaaS resolves this:

• Istio integration: Istio’s certificate authority (istiod) can be configured to use an external CA plugin. cert-manager’s istio-csr component acts as a bridge between Istio’s certificate signing request mechanism and the PKIaaS CA: istiod sends CSRs to istio-csr, which forwards them to the PKIaaS CA via cert-manager, and the signed certificates are returned to istiod for distribution to Envoy sidecars. All service mesh certificates are now issued by the PKIaaS CA and visible in the CLM inventory;
• Linkerd integration: Linkerd’s control plane uses a trust anchor certificate and an issuer certificate for proxy certificate issuance. cert-manager can provision and automatically renew both the trust anchor and the issuer certificate from the PKIaaS CA, ensuring Linkerd’s proxy certificates chain to the organization’s private CA rather than to a self-signed Linkerd-internal CA.

Machine Certificate Enrollment for On-Premises Environments

Not all machines in a hybrid environment run in Kubernetes or cloud-native runtimes. On-premises servers, network appliances, and legacy application servers also need machine certificates for mTLS and internal API authentication. PKIaaS supports enrollment for these environments through EST and SCEP.

EST (Enrollment over Secure Transport)

EST (RFC 7030) is the IETF standard for certificate enrollment over HTTPS. EST is preferred over SCEP for new deployments because it uses standard HTTPS transport (no special port or protocol required), supports mutual TLS for client authentication before certificate issuance (preventing unauthenticated enrollment), provides explicit certificate re-enrollment and CA certificate retrieval operations, and is supported by modern enterprise network devices and Linux-based systems.

For on-premises machines, EST enrollment through the PKIaaS EST endpoint works as follows: the machine generates a key pair locally, constructs a PKCS#10 CSR, authenticates to the PKIaaS EST endpoint using an initial shared secret or a previously issued certificate (for re-enrollment), submits the CSR, and receives the signed certificate. Renewal is handled by the EST client re-enrolling before the current certificate expires. EST clients are available for Linux (est-client, OpenSSL-based implementations), network appliances, and embedded systems that support RFC 7030.

CMP for Embedded and Edge Devices

CMP (Certificate Management Protocol, RFC 4210) is used in environments where EST and ACME are not appropriate: industrial control systems, programmable logic controllers, embedded devices with constrained network stacks, manufacturing equipment, and telco infrastructure. CMP is more complex than EST but provides comprehensive certificate management operations including initial enrollment, certificate renewal, certificate revocation, and CA key update notification, in a protocol designed for environments where the enrolling device may have limited computational resources or operate over constrained network links.

For hybrid environments with on-premises OT (operational technology) or edge infrastructure alongside cloud-native workloads, PKIaaS CMP support means the same CA hierarchy can issue certificates for both a Kubernetes microservice running in the cloud and an industrial controller on the factory floor. The CLM layer provides unified visibility across both, surfacing certificate expiry alerts for edge device certificates that would otherwise have no monitoring.

Securing Internal APIs with PKIaaS Machine Certificates

Internal APIs are among the highest-value targets in a hybrid enterprise environment. An internal API that accepts requests from any caller on the internal network (without machine identity verification) is accessible to any compromised machine that has network access, any developer workstation on a flat network segment, and any lateral movement path an attacker has established. mTLS on internal APIs eliminates network-location-based trust for API access.

For REST APIs and gRPC services in hybrid environments, PKIaaS machine certificates enable the following API security architecture:

• Per-service client certificates: Each service that calls the internal API is issued a client certificate from the PKIaaS CA. The API server’s TLS configuration requires client certificate presentation and validates the certificate chain against the PKIaaS CA. The API server can read the client certificate’s Subject CN or URI SAN to identify the calling service and apply service-level authorization policies (Service A is permitted to call the /orders read endpoint; Service B is not);
• API gateway certificate enforcement: Internal API gateways (Kong, Apigee, or cloud-native API gateways) can be configured to enforce client certificate validation before routing requests to upstream services. The gateway reads the client certificate, validates it against the PKIaaS CA trust chain, and passes the verified caller identity to the upstream service as a header or context attribute;
• Short-lived API call certificates for sensitive operations: For high-privilege API calls (administrative operations, bulk data access, configuration changes), PKIaaS can issue certificates valid only for the duration of the specific operation (minutes to hours) rather than for a standard service certificate validity period. The API server checks both that the certificate is valid and that it was issued within the expected time window for the operation type.

Trust Domain Design for Hybrid Environments

Hybrid environments span multiple administrative domains: the organization’s on-premises data center, one or more public cloud accounts, Kubernetes clusters in different regions, edge deployment zones, and partner or acquired organization networks. The PKIaaS CA hierarchy design must account for this topology to provide meaningful trust isolation between environments.

The recommended design uses a single PKIaaS root CA with environment-specific issuing CAs, mirroring the multi-cluster governance model described for platform engineering but applied to the full hybrid estate:

• Environment-specific issuing CAs: A production issuing CA for production workloads, a non-production issuing CA for development and staging, and separate issuing CAs for regulated environments (those subject to data residency or compliance isolation requirements). Certificates issued by the production issuing CA cannot authenticate to non-production services whose trust stores contain only the non-production issuing CA, providing cryptographic environment isolation;
• Cloud-specific issuing CAs: For organizations with multi-cloud deployments where workloads in one cloud provider should not be able to authenticate to services in another cloud provider without explicit cross-CA trust configuration, cloud-specific issuing CAs provide the isolation boundary. Trust between cloud environments is established by explicit trust anchor distribution, not by default;
• Edge issuing CAs with offline capability: Edge environments with intermittent connectivity to the PKIaaS management plane may require an edge issuing CA that can issue certificates locally when the connection to the central PKIaaS CA is unavailable. The edge issuing CA is issued by the PKIaaS root CA; its certificates are trusted by the same root CA trust store. Certificate issuance at the edge continues during connectivity gaps; revocation is synchronized when connectivity is restored;
• Partner and acquisition integration: For acquired organizations or partner networks that need to participate in the machine identity trust domain, the PKIaaS CA can issue a cross-certification certificate to the partner’s existing CA (or issue a new issuing CA under the PKIaaS root) without requiring the partner to replace their existing certificate infrastructure immediately.

Machine Certificate Lifecycle Management at Scale

Machine certificates have a different failure mode than user certificates. When a user’s certificate expires, one user loses access and reports it to the helpdesk. When a machine certificate expires in a service mesh or mTLS-protected microservices architecture, service-to-service calls fail. Depending on how error handling is implemented, this can cascade: Service A cannot call Service B, so Service A returns errors to Service C, which fails its own operations, producing symptoms that look like a network outage or application bug rather than a certificate expiry. Diagnosing a certificate expiry in a cascade failure scenario is time-consuming and disruptive.

CLM for machine certificates prevents this failure mode by providing:

• Unified machine certificate inventory: The CLM platform connected to the PKIaaS CA maintains an inventory of every machine certificate issued across all environments: Kubernetes cluster certificates, on-premises server certificates, edge device certificates, network appliance certificates, and API gateway certificates. Each certificate entry records the issuing CA, the subject and SANs, the validity period, the enrollment protocol used, and the associated service or machine identity;
• Expiry monitoring with environment-aware alerting: For production machine certificates, expiry alerts route to the service team and the infrastructure team responsible for that service’s certificate management. For edge device certificates, alerts route to the edge operations team. Alert thresholds for machine certificates should be set earlier than for user certificates (30 days, 14 days, 7 days) because machine certificate renewal failures in production environments have higher immediate impact than user certificate renewal failures;
• Automated renewal confirmation: The CLM platform monitors whether certificates are renewed before expiry by comparing the expected renewal date (based on the certificate’s validity period and the configured renewal threshold) against the issuance timestamp of the most recently issued certificate for each machine identity. If no new certificate has been issued within the expected renewal window, the CLM flags the certificate as at risk and initiates the alert path;
• Decommission tracking: When a service is decommissioned, its certificate should be revoked. The CLM platform should flag active certificates for services that have been removed from the service registry, alerting the PKI administration team to revoke orphaned machine certificates. An orphaned certificate for a decommissioned service is a security liability: if the service’s private key was not destroyed at decommission, the certificate could be misused to authenticate as that service to other services that still trust it.

How Encryption Consulting Can Help

• PKI as a Service: Encryption Consulting’s PKIaaS offering provides the governed CA infrastructure for machine-to-machine identity across hybrid environments: mTLS machine certificate profiles (TLS Client Auth EKU, TLS Server Auth EKU, SPIFFE URI SAN support), multi-environment CA hierarchy design (production/non-production/edge/cloud-specific issuing CAs), ACME endpoint for cloud-native machine enrollment, EST endpoint for Linux server and network appliance enrollment, CMP for embedded and edge devices, and CA Gateway API for programmatic certificate issuance from DevOps toolchains and infrastructure-as-code pipelines. Contact us at Encryption Consulting to design your hybrid machine identity architecture.
• CertSecure Manager: Encryption Consulting’s CertSecure Manager provides the CLM layer for machine certificate lifecycle management: unified machine certificate inventory across on-premises, cloud, Kubernetes, and edge environments, expiry monitoring with environment-aware and service-team-specific alert routing, automated renewal confirmation monitoring, decommission tracking for orphaned machine certificates, and SIEM integration for machine certificate lifecycle events alongside infrastructure security events.
• PKI Services (Machine Identity Architecture): Encryption Consulting’s PKI Services include machine identity architecture design for hybrid environments: CA hierarchy design for multi-environment trust isolation, cert-manager ClusterIssuer configuration for Kubernetes machine certificates, SPIRE upstream CA integration with PKIaaS, service mesh certificate integration (Istio istio-csr and Linkerd trust anchor provisioning), EST and CMP enrollment configuration for on-premises and edge devices, and mTLS enforcement design for internal API gateway and service mesh architectures.
• CBOM Secure: For organizations that do not have a complete inventory of machine certificates in their hybrid environment, Encryption Consulting’s CBOM Secure provides automated cryptographic discovery across the network and infrastructure, identifying every certificate in use across servers, containers, network devices, and cloud workloads. The CBOM output provides the machine certificate inventory baseline from which the CLM monitoring program begins, and identifies certificates from unknown or self-signed CAs that indicate ungoverned machine identity in the environment.
• PKI Assessment Service: For organizations evaluating a transition from shared-secret M2M authentication to certificate-based mTLS, Encryption Consulting’s PKI Assessment Service evaluates the current machine identity architecture, maps each service-to-service authentication pattern to the appropriate certificate type and enrollment mechanism, identifies the highest-risk ungoverned machine identity gaps, and produces an implementation roadmap for the M2M certificate program.

Conclusion

Machine-to-machine identity is the authentication problem that most hybrid enterprises have not fully solved. Shared secrets accumulate, rotate inconsistently, and provide no cryptographic binding between the credential and the specific machine holding it. mTLS with PKIaaS-issued certificates is the correct solution: cryptographic identity for every machine entity, automatic authentication at the TLS layer before any application processing, instant revocation when a machine is compromised or decommissioned, and CLM-level visibility across the entire machine certificate estate.

The hybrid nature of modern infrastructure (cloud workloads, on-premises servers, Kubernetes clusters, edge devices) does not make this harder; it makes it more urgent. A machine that is not in the PKIaaS trust domain can call any service that trusts the network location instead of a certificate. Every service that moves to mTLS enforcement narrows the attack surface available to a compromised machine by exactly the set of services that machine’s certificate does not authorize it to access.

The practical path is incremental: start with the highest-risk service-to-service communications (internal APIs handling sensitive data, services with privileged access to databases or key management systems), issue certificates to those services from the PKIaaS CA, enforce mTLS, and expand the certificate-required trust domain outward as the automation and monitoring stack matures. CLM visibility into the machine certificate estate makes each increment of coverage measurable.

If your organization is designing machine identity for a hybrid environment or assessing the current state of M2M authentication, reach out to Encryption Consulting.

This post is reviewed on a six-month cadence and when CNCF SPIFFE/SPIRE, cert-manager, Istio, or major cloud provider service mesh integrations publish updates that affect PKIaaS machine identity architecture patterns.

Frequently Asked Questions

What is machine-to-machine identity and why does it require PKI?

Machine-to-machine identity is the process by which a service, application, or device proves its identity to another without human interaction. PKI provides this through certificates: each machine receives a certificate from the private PKIaaS CA, presents it when initiating connections, and is validated or rejected based on whether the certificate is valid, unrevoked, and issued by a trusted authority. Unlike shared secrets, the private key never leaves the machine and there is no shared credential that an attacker can steal and reuse from a different machine.

What is mTLS and how does it differ from standard TLS?

Standard TLS authenticates only the server to the client. mTLS (mutual TLS) requires both the server and the client to present certificates, authenticating both parties before any application data is exchanged. For M2M communication, mTLS means a service cannot receive requests from any caller that lacks a valid certificate from the trusted PKIaaS CA, regardless of the caller’s network location. Authentication happens at the TLS layer before application-level processing, eliminating network-location-based implicit trust.

What is SPIFFE and how does it relate to PKIaaS machine identity?

SPIFFE (Secure Production Identity Framework for Everyone) is a CNCF open standard for cloud-native workload identity. SPIFFE SVIDs are X.509 certificates with the workload’s SPIFFE ID encoded as a URI SAN. SPIRE (the reference implementation) can be configured to use the PKIaaS CA as its upstream authority, so SPIFFE-identified workloads receive SVIDs that chain to the organization’s private CA trust hierarchy rather than a SPIRE-internal self-signed CA.

How does cert-manager integrate with PKIaaS for Kubernetes machine identity?

cert-manager is the Kubernetes certificate management controller. The platform team configures a cert-manager ClusterIssuer pointing at the PKIaaS ACME endpoint or CA Gateway API. Services declare Certificate resources specifying subject and SANs; cert-manager handles issuance, stores the certificate as a Kubernetes Secret, and renews it automatically before expiry. For service meshes, cert-manager’s istio-csr component bridges Istio certificate signing requests to the PKIaaS CA, making service mesh certificates visible in the CLM inventory.

What enrollment protocols does PKIaaS support for machine certificate enrollment across hybrid environments?

PKIaaS supports ACME (RFC 8555) for cloud-native and Linux machines, EST (RFC 7030) for enterprise servers and network appliances, CMP (RFC 4210) for embedded and edge devices, and SCEP for network devices and MDM-enrolled machines. A single PKIaaS CA management plane governs all certificate issuance regardless of which enrollment protocol the machine uses, providing unified policy enforcement and CLM inventory across the full hybrid machine estate.