Private PKI for Zero Trust Networks: Where PKIaaS Fits

Zero Trust is a security model, not a product. The core of it, as defined in NIST Special Publication 800-207, is that no user, device, or workload should be granted access to a resource based on network location alone. Every access request requires verification. Every connection requires authenticated identity. Every policy decision requires evidence that the requesting entity is who it claims to be.

That last requirement is where private PKI becomes non-optional. Certificate-based authentication is the most scalable, cryptographically verifiable mechanism for establishing identity at the user, device, and workload layers that Zero Trust policies evaluate. Passwords can be phished. Network location can be spoofed. A certificate signed by a governed private CA, bound to a specific identity, presented over a cryptographically protected channel, with a verifiable revocation status, is a materially stronger identity claim than any of those alternatives.

This post is not about Zero Trust marketing. It is about the specific role that private PKI and PKI as a Service play in the technical implementation of a Zero Trust program: which identity problems they solve, how they connect to the NIST ZTA logical components, and how PKIaaS fits into the practical stack of tools most organizations use to implement Zero Trust.

Quick Answer: What Does Private PKI Do in a Zero Trust Program?

Private PKI provides the cryptographic identity infrastructure for the identity pillar of Zero Trust: issuing and managing the certificates that prove who a user is (client certificate for authentication), what device is connecting (device identity certificate for MDM-enrolled endpoints), which service is calling which other service (workload identity certificate for mTLS), and whether a software artifact is authentic (code signing certificate for supply chain integrity). PKIaaS provides that CA infrastructure as a governed, FIPS-validated managed service, removing the operational burden of running it internally while maintaining the certificate policy control and audit trail that Zero Trust policy enforcement depends on.

Key Takeaways

• NIST SP 800-207 defines Zero Trust through seven tenets. Tenets 1 (all data sources and computing services are resources), 2 (all communication is secured regardless of network location), and 3 (access is granted per-session on a least-privilege basis) are directly enabled by certificate-based authentication and mTLS. Private PKI is the infrastructure layer that makes those tenets technically enforceable.
• Zero Trust has five identity targets that private PKI addresses: user identity (client certificates for MFA and passwordless authentication), device identity (MDM-provisioned device certificates for endpoint posture verification), workload identity (service certificates for mTLS), network infrastructure identity (TLS certificates for internal services and APIs), and software supply chain identity (code signing certificates for build pipeline integrity).
• Device identity certificates are the Zero Trust entry point for PKIaaS. An MDM-enrolled device with a PKIaaS-issued device certificate presents that certificate to a NAC system or ZTNA gateway as proof of managed device status. Without the device certificate, the device cannot satisfy the device posture requirement of the Zero Trust policy, even if the user authenticates successfully.
• mTLS for service-to-service authentication is the workload layer equivalent of Zero Trust. Rather than trusting internal service traffic because it is on the internal network, mTLS requires every service connection to authenticate with a certificate. A private CA (PKIaaS) issues those service identity certificates and provides the trust anchor that each service verifies its peer against.
• PKIaaS audit logs are a Zero Trust policy input. NIST SP 800-207 defines continuous monitoring and validation as a Zero Trust requirement. The PKIaaS CA’s audit log of certificate issuance, renewal, and revocation events provides the certificate lifecycle evidence that Zero Trust policy engines and SIEM systems need to continuously validate that device and workload certificates in use are current, not revoked, and issued under policy.

NIST SP 800-207 and the Role of PKI

NIST Special Publication 800-207, published in August 2020, is the definitive US government guidance document for Zero Trust Architecture. It defines Zero Trust as an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to a focus on users, assets, and resources. The seven tenets of Zero Trust defined in SP 800-207 establish the principles against which any Zero Trust implementation should be evaluated.

Several of these tenets directly require the identity and encryption capabilities that private PKI provides:

Tenet 2: All communication is secured regardless of network location. Every connection between any two entities, regardless of whether that connection crosses a network segment boundary, must be authenticated and encrypted. TLS with mutual authentication (mTLS) is the implementation mechanism for this tenet in network communication. Private PKI provides the CA infrastructure that issues the certificates both endpoints use for authentication and key exchange.

Tenet 3: Access to individual enterprise resources is granted on a per-session basis. Each access request is evaluated against the current state of the requesting entity (user identity, device identity, device posture, request context). Certificate-based authentication contributes device and workload identity evidence to each access decision, alongside user authentication from an IdP and device posture from an MDM platform.

Tenet 4: Access to resources is determined by dynamic policy including the observable state of client identity and behavior. The observable state of a device includes whether it has a valid, currently issued certificate from the organization’s PKI. A device whose certificate has expired or been revoked presents a changed state that Zero Trust policy can use to deny or restrict access. The PKIaaS audit log and OCSP responder provide the real-time certificate validity data that Zero Trust policy engines need.

Tenet 6: All enterprise assets have their authentication and authorization dynamically enforced before access is allowed. Workload identity certificates (SPIFFE SVIDs issued by a PKIaaS-rooted SPIRE server, or service certificates managed by cert-manager) provide the cryptographic identity that Zero Trust policy enforcement points evaluate for service-to-service access decisions.

NIST SP 800-207 also defines three logical components of a Zero Trust Architecture: the Policy Engine, Policy Administrator, and Policy Enforcement Point (PEP). PKI sits in the identity data layer that feeds the Policy Engine: the PKIaaS CA’s issued certificates are the identity claims that the Policy Engine evaluates when making access decisions. The revocation status information from the PKIaaS OCSP responder is the real-time validity data the Policy Engine uses for continuous validation.

User Identity: Certificate-Based Authentication and Passwordless

Password-based authentication is structurally incompatible with strong Zero Trust requirements. Passwords can be phished, reused across accounts, stolen from breached credential stores, or brute-forced. Multi-factor authentication with TOTP or push notifications reduces but does not eliminate these risks. Certificate-based authentication eliminates most of them: a certificate private key cannot be phished, cannot be reused across accounts, and cannot be stolen from a credential store because it never leaves the hardware or software keystore it was generated in.

Private PKI enables certificate-based user authentication through several mechanisms:

Smart card and virtual smart card logon: User certificates issued by a private CA, stored on hardware tokens or in TPM-backed virtual smart card stores, enable certificate-based Windows domain logon (Kerberos PKINIT), TLS client authentication for web applications, and S/MIME email signing and encryption. These certificates bind the user’s identity (from Active Directory or an identity provider) to a cryptographic key pair, producing an authentication factor that is resistant to phishing, credential stuffing, and remote credential theft.

TLS client certificate authentication for web applications and APIs: Web applications and API gateways configured to require TLS client certificates implement certificate-based MFA at the protocol level. The user’s browser or application presents the client certificate; the server verifies it against the private CA trust anchor. This satisfies the Zero Trust requirement that every access request be authenticated before access is granted, using a mechanism that is cryptographically verifiable rather than knowledge-based.

Integration with IdP and SSO infrastructure: Modern IdPs (Azure AD/Entra ID, Okta, Ping Identity) support certificate-based authentication as a first factor or as part of an MFA flow. A user certificate issued by the organization’s private PKI can be used as the primary authenticator in an IdP-mediated SSO session, providing phishing-resistant authentication that satisfies NIST AAL2 and AAL3 requirements from NIST SP 800-63B without requiring hardware FIDO2 tokens.

PKIaaS enables user certificate provisioning at scale by integrating with MDM platforms (Microsoft Intune, Jamf, VMware Workspace ONE) for automated certificate issuance to managed devices, and with Active Directory through a WSTEP autoenrollment proxy for domain-joined Windows machines. Every managed user device can have a user certificate provisioned automatically without manual intervention from the PKI team.

Device Identity: The Zero Trust Entry Point for PKIaaS

Device identity is the most operationally critical PKI use case in a Zero Trust program. NIST SP 800-207 explicitly includes device identity in the entity set that Zero Trust policies evaluate: a user authenticating from an unmanaged or non-compliant device should not receive the same access as the same user authenticating from a managed, compliant device. Device certificates are the cryptographic mechanism that makes device identity verifiable rather than asserted.

Device Certificate Provisioning via MDM

Device identity certificates are issued to managed devices through MDM-integrated enrollment. The MDM platform (Intune, Jamf, Workspace ONE) creates a SCEP or PKCS certificate profile that points to the PKIaaS SCEP endpoint. When a device enrolls in MDM, it automatically receives a device certificate from the PKIaaS CA. The certificate contains the device’s identity attributes (machine name, device ID, organizational unit) and is stored in the device’s certificate store or TPM-backed key storage.

The device certificate lifecycle is managed through MDM: renewal is triggered automatically by the MDM platform before the certificate expires; revocation is triggered when the device is unenrolled from MDM, reported lost or stolen, or determined to be non-compliant. The PKIaaS CA’s CRL and OCSP responder reflect revocations in real time, enabling Zero Trust policy enforcement points to detect and deny access from devices whose certificates have been revoked.

Device Certificate Enforcement at Access Points

Device certificates are evaluated at several points in the Zero Trust access flow:

802.1X network access control: Network access control systems require a valid device certificate from the organizational PKI before a device is permitted onto the network. This enforces that only MDM-managed devices with a current PKIaaS-issued device certificate can connect to corporate network segments. Unmanaged devices, personal devices, and devices whose MDM enrollment has lapsed (and whose certificate has been revoked) are denied network access at the 802.1X enforcement point regardless of whether the user has valid credentials.

ZTNA gateway device posture checks: Zero Trust Network Access gateways evaluate device posture as part of the access decision. A device certificate issued by the organization’s trusted PKI is a posture signal that indicates the device is managed and enrolled. ZTNA gateways that support certificate-based device posture checks can verify that the device certificate chain leads to the organization’s PKIaaS root CA, that the certificate has not expired, and (via OCSP) that it has not been revoked, as part of each session establishment.

Conditional Access policies: Identity platforms with Conditional Access (Azure AD Conditional Access, Okta Adaptive MFA) can be configured to require a compliant device certificate as a condition for accessing specific resources. A user attempting to access a sensitive application from a device without a valid organizational device certificate fails the Conditional Access policy, regardless of the strength of their user authentication.

Workload Identity: Zero Trust for Service-to-Service Communication

Zero Trust for service-to-service communication requires that every service authenticate its peer before accepting a connection, regardless of network segment. In a traditional enterprise network, services on the same subnet trusted each other implicitly. In a Zero Trust architecture, a database service does not trust an application service simply because they are on the same VLAN; the application service must present a certificate that the database service can verify against a trusted CA before the connection is accepted.

This is mutual TLS (mTLS) at the service layer, and it requires a private CA to issue service identity certificates. The service identity certificates encode the service’s identity (typically as a DNS SAN matching the service’s DNS name, or as a SPIFFE ID URI SAN for SPIFFE-compliant environments) and are signed by the organization’s PKIaaS CA. Each service verifies its peer’s certificate against the PKIaaS root CA trust bundle before the mTLS handshake completes.

For organizations running Kubernetes, service mesh (Istio, Linkerd) provides mTLS between all services in the mesh automatically, using short-lived certificates (typically 24-hour validity) issued by a mesh intermediate CA backed by the PKIaaS root. This eliminates the need to configure mTLS manually for each service pair and provides automatic certificate rotation without operator intervention. The PKIaaS multi-cloud architecture guide at Multi-Cloud PKIaaS Architecture Guide covers the cert-manager and service mesh integration patterns in detail.

For non-Kubernetes workloads, service identity certificates can be provisioned through ACME (for Linux services), EST (for network devices and constrained endpoints), or through the PKIaaS REST API from infrastructure automation tools (Ansible, Terraform, Puppet). The key requirement is that every service has a certificate and that every service enforces mTLS with certificate verification against the PKIaaS root, not just encryption without peer authentication.

Network Infrastructure Identity: TLS Everywhere

Zero Trust requires that all communication be secured regardless of network location. In practice, this means that every internal service, API, dashboard, and administrative interface must be served over TLS, not HTTP. Many organizations have a gap here: internal tools are often served over HTTP on internal networks because the assumption is that the internal network is trusted. Zero Trust eliminates that assumption.

Private PKI enables TLS everywhere by providing a CA that can issue certificates for internal hostnames (names that do not need to be publicly trusted and therefore do not require a public CA). Internal names like api.internal.example.com, dashboard.prod.svc.cluster.local, or 192.168.1.100 cannot receive certificates from public CAs under current CA/Browser Forum requirements. A private CA can issue certificates for any name that the CA’s certificate policy permits, enabling TLS to be deployed across internal infrastructure that public CAs cannot serve.

PKIaaS combined with certificate lifecycle automation (via ACME and cert-manager) makes TLS everywhere operationally achievable. Manual certificate management for hundreds or thousands of internal services is not feasible; automated issuance and renewal through PKIaaS is. The CA/Browser Forum’s Ballot SC-081v3 (approved April 2025) reducing maximum public TLS certificate validity to 47 days by March 15, 2029 reinforces the point: manual certificate management is not a long-term operational model. Private PKIaaS with automation is.

Software Supply Chain Identity: Code Signing in Zero Trust

Zero Trust applies to software as well as to users and devices. The NIST Cybersecurity Framework and CISA guidance on software supply chain security treat software authenticity as a security control: a workload should only execute code that is verifiably authentic and has not been tampered with. Code signing certificates issued by a private CA provide the cryptographic mechanism for this verification.

In a Zero Trust software supply chain, build pipelines sign container images, binaries, and scripts with a code signing certificate issued by the organization’s PKIaaS CA. Deployment systems (Kubernetes admission webhooks, container registries with signature verification, OS-level application control policies) verify the signature against the PKIaaS CA trust bundle before executing the artifact. An unsigned artifact, or one signed with a certificate from an untrusted CA, is rejected at the deployment enforcement point.

This is the supply chain equivalent of Zero Trust’s “never trust, always verify” principle applied to software: every artifact that executes in the environment must have a verifiable identity claim. Code signing certificates with HSM-backed private keys (so signing keys cannot be exfiltrated from build infrastructure) and short validity periods (so compromised signing certificates expire quickly) satisfy the Zero Trust requirement for continuous verification even in the software supply chain layer.

Continuous Verification: CLM and OCSP as Zero Trust Inputs

NIST SP 800-207 Tenet 4 requires that Zero Trust policies be based on the dynamic, observable state of the requesting entity. For certificate-based identity, this means Zero Trust policies must be able to evaluate whether a certificate is currently valid, not just whether it was valid when it was issued. Two PKI mechanisms provide this capability: OCSP and certificate lifecycle management.

OCSP (Online Certificate Status Protocol) provides real-time certificate validity checking. When a Zero Trust policy enforcement point (a ZTNA gateway, a NAC system, a service mesh sidecar) receives a certificate, it can query the PKIaaS OCSP responder to confirm that the certificate has not been revoked since it was issued. A certificate that passes chain trust validation but has been revoked (because the device was unenrolled from MDM, the user account was terminated, or the service was decommissioned) is detected and rejected in real time. PKIaaS providers operate OCSP responders for all issued certificates; the OCSP responder URL is embedded in every issued certificate in the Authority Information Access extension.

Certificate lifecycle management as continuous compliance. A CLM platform connected to the PKIaaS CA provides continuous monitoring of the certificate estate against current policy. Certificates that deviate from current policy (key sizes below minimum, validity periods exceeding current maximums, certificates issued to decommissioned hosts) are flagged and can trigger automatic remediation or alerts to the Zero Trust policy team. This satisfies the Zero Trust requirement that the observable state of assets be continuously monitored rather than evaluated only at initial access.

Encryption Consulting’s CertSecure Manager provides both functions: real-time certificate inventory across the full PKIaaS-issued certificate estate, expiry monitoring with configurable advance alerting, policy compliance checking, and SIEM integration that feeds certificate lifecycle events into the same security monitoring stack that processes OCSP queries and Zero Trust policy engine events.

CISA Zero Trust Maturity Model: Where PKI Fits

CISA’s Zero Trust Maturity Model (ZTMM), updated November 2023, provides a five-pillar framework for implementing Zero Trust: Identity, Device, Network, Application Workload, and Data. Private PKI and PKIaaS contribute to three of these pillars directly.

Identity pillar: At the Optimal maturity level of the CISA ZTMM Identity pillar, agencies use phishing-resistant MFA for all users, enforce continuous validation of user and device identity, and automate lifecycle management of credentials. Certificate-based authentication (PIV/CAC for federal agencies, private PKI user certificates for enterprise environments) is the primary mechanism for phishing-resistant MFA at this maturity level. PKIaaS automated certificate lifecycle management satisfies the automation requirement at this pillar level.

Device pillar: At the Advanced to Optimal maturity levels of the Device pillar, organizations use automated device authentication with certificate-based device identity, continuously validate device compliance before granting resource access, and integrate device identity with conditional access policies. PKIaaS with MDM integration provides the device certificate provisioning and lifecycle management that enables these capabilities. The device certificate issued by PKIaaS to an MDM-enrolled endpoint is the cryptographic claim that the Device pillar’s access policies evaluate.

Application Workload pillar: At higher maturity levels of the Application Workload pillar, organizations use workload identity certificates for service-to-service mTLS and integrate certificate-based workload identity with application-level authorization controls. SPIFFE/SPIRE-based workload identity backed by a PKIaaS root CA, and service mesh mTLS with PKIaaS-issued sidecar certificates, are the implementation mechanisms for this pillar at higher maturity levels.

Where PKIaaS Fits in the Zero Trust Technology Stack

A practical Zero Trust technology stack typically includes: an identity provider (IdP) for user authentication; an MDM platform for device management and compliance; a network access control system or ZTNA gateway for network-level enforcement; a service mesh or mTLS framework for workload-level enforcement; and a SIEM for continuous monitoring and anomaly detection. Private PKI and PKIaaS are not a separate layer in this stack. They are the identity infrastructure layer that provides the certificates that every other layer in the stack depends on.

The IdP uses certificates for phishing-resistant authentication. The MDM platform uses certificates to prove device enrollment status. The NAC system uses certificates to authenticate devices at the network layer. The ZTNA gateway uses certificates to verify device posture. The service mesh uses certificates to authenticate services to each other. The code signing system uses certificates to authenticate software artifacts. In each case, the certificate must be issued by a trusted CA under a documented certificate policy, and its current validity must be verifiable through OCSP or CRL. PKIaaS provides that CA, that policy, and that revocation infrastructure as a managed service.

How Encryption Consulting Can Help

Encryption Consulting helps organizations design and implement the private PKI infrastructure that underpins their Zero Trust programs, from initial architecture through PKIaaS deployment, MDM integration, and CLM governance.

• PKI as a Service: Encryption Consulting’s PKIaaS offering provides the FIPS 140-3 Level 3 HSM-backed CA infrastructure for all five Zero Trust identity targets: user certificates (via MDM and WSTEP autoenrollment), device certificates (via native Intune, Jamf, and Workspace ONE integration), workload identity certificates (via ACME+EAB for cert-manager and SPIRE upstream CA), internal TLS certificates (via ACME and REST API), and code signing certificates (via REST API with HSM-backed key storage). Contact us at Encryption Consulting to discuss your Zero Trust PKI requirements.
• PKI Assessment Service: For organizations building a Zero Trust program and needing to understand whether their current PKI provides the certificate-based identity capabilities Zero Trust requires, Encryption Consulting’s PKI Assessment Service maps the current PKI architecture against the Zero Trust identity requirements of NIST SP 800-207 and the CISA ZTMM Device and Application Workload pillar requirements, and produces a gap analysis and remediation roadmap.
• CertSecure Manager: Encryption Consulting’s CertSecure Manager provides the CLM layer that makes certificate-based Zero Trust sustainable over time: continuous certificate discovery, expiry monitoring with SIEM integration, policy compliance checking, and automated renewal across the full PKIaaS-issued certificate estate. Real-time certificate validity data feeds Zero Trust policy engines and SIEM platforms with the continuous monitoring inputs that NIST SP 800-207 Tenet 4 requires.
• Compliance Advisory Services: For organizations subject to federal Zero Trust mandates (OMB M-22-09 for federal agencies, which required Zero Trust adoption by FY2024, or CISA ZTMM guidance) or regulated-sector Zero Trust requirements, Encryption Consulting’s Compliance Advisory Services provide structured support for mapping PKI capabilities to the specific maturity level requirements of the applicable Zero Trust framework.
• PQC Advisory Services: Zero Trust programs that are being designed now will need to accommodate post-quantum cryptography within the NIST IR 8547 window (RSA/ECC deprecation approximately 2030). The certificates at the center of a Zero Trust program, user certificates, device certificates, and workload identity certificates, will all need to migrate to ML-DSA or hybrid algorithms. Encryption Consulting’s PQC Advisory Services integrate PQC migration planning into Zero Trust architecture design rather than treating it as a separate future project.

Conclusion

Zero Trust is a meaningful security architecture when it is implemented with the technical controls that make its principles enforceable. The principle that all communication must be secured regardless of network location is not enforceable without TLS and the private PKI that makes TLS certificates available for internal services. The principle that access decisions must be based on verified device identity is not enforceable without device certificates and the MDM-integrated PKIaaS that provisions them. The principle that workload-to-workload communication must be authenticated is not enforceable without mTLS and the workload identity certificates that mTLS depends on.

None of these controls require overhauling an organization’s entire infrastructure at once. A Zero Trust program that starts with device identity certificates via MDM integration with PKIaaS, extends to TLS everywhere on internal services through cert-manager automation, and then adds workload mTLS through a service mesh backed by PKIaaS intermediate CAs is making incremental, measurable progress on each pillar of the CISA ZTMM framework with each phase.

PKIaaS is the practical implementation choice for organizations that want to build a strong certificate identity foundation without the operational overhead of running the CA infrastructure themselves. The CA is governed, FIPS-validated, audited under SOC 2 Type II, and available to serve certificate requests across the full range of protocols that a modern enterprise environment uses, from ACME for cloud workloads to WSTEP for Windows domain machines to SCEP for MDM-managed mobile devices.

If your organization is building or extending a Zero Trust program and needs a clear picture of where private PKI fits, reach out to Encryption Consulting. We help security architects map certificate-based identity capabilities to Zero Trust framework requirements and design the PKIaaS deployment that makes those capabilities operational.

This post is reviewed on a six-month cadence and when NIST, CISA, or OMB publish material updates to Zero Trust guidance, or when the NIST SP 800-207 revision process produces a significant update to the Zero Trust Architecture specification.

Frequently Asked Questions

Why does Zero Trust require private PKI?

Zero Trust requires continuous, cryptographic verification of identity before granting access. Private PKI provides the cryptographic identity foundation: certificates issued by a governed private CA bind a verified identity to a public key, enabling authentication protocols (TLS client auth, 802.1X, Kerberos PKINIT, mTLS) that are cryptographically verifiable and policy-governed. Without private PKI, device and workload identity layers typically rely on weaker mechanisms that do not provide the same assurance.

What is the difference between user identity and device identity in Zero Trust?

User identity verifies who is accessing a resource, typically through an IdP with MFA. Device identity verifies that the device is managed, enrolled in MDM, and compliant. Device identity certificates issued by a private CA provide the cryptographic device identity that Zero Trust policies evaluate independently from user authentication. A legitimate user credential on an unmanaged device is insufficient to satisfy a Zero Trust policy that requires both.

How does mTLS support Zero Trust for service-to-service communication?

mTLS requires both the server and client to present and verify certificates before a connection proceeds. In a Zero Trust service mesh, mTLS enforces that every service-to-service connection is between verified, authenticated services. This satisfies the Zero Trust principle that no traffic is implicitly trusted based on network location. Private PKI issues the service identity certificates used in mTLS; PKIaaS provides that CA infrastructure as a managed service.

Does Zero Trust eliminate the need for network segmentation?

No. NIST SP 800-207 explicitly states that Zero Trust does not eliminate the need for network security controls. Microsegmentation remains a defense-in-depth control that limits blast radius. PKI-based device and workload identity enables policy enforcement based on cryptographic identity rather than IP address, but network controls continue to provide a complementary layer of protection.

What NIST publications define Zero Trust Architecture?

NIST Special Publication 800-207 (August 2020) is the primary NIST guidance document for Zero Trust. It defines the seven tenets of Zero Trust, describes three logical components (Policy Engine, Policy Administrator, Policy Enforcement Point), and provides deployment models. CISA’s Zero Trust Maturity Model (updated November 2023) provides a five-pillar (Identity, Device, Network, Application Workload, Data) maturity framework with PKI-based device and workload identity spanning the Device and Application Workload pillars.

Can PKIaaS integrate with existing Zero Trust infrastructure?

Yes. PKIaaS integrates with Zero Trust infrastructure at the identity layer: device certificates are used by NAC systems for 802.1X authentication, by ZTNA gateways for device posture validation, and by IdPs for certificate-based MFA. PKIaaS with native MDM integration (Intune, Jamf, Workspace ONE) automatically provisions device certificates to managed devices, ensuring the device identity required by Zero Trust policies is present on every managed endpoint without manual provisioning.