Non-Human Identity Security: Managing Service Accounts at CDN Scale

Every CDN edge node runs dozens of services that authenticate to each other, to origin servers, to monitoring platforms, and to configuration stores. Each of these service-to-service interactions requires an identity, and in a global CDN with hundreds of Points of Presence, the number of non-human identities (NHIs) dwarfs the human workforce by orders of magnitude. Yet most organizations still manage these machine identities with the same ad-hoc approaches they used a decade ago: long-lived API keys stored in environment variables, shared service accounts with broad permissions, and certificates that expire unexpectedly because nobody tracked their renewal dates.

The consequences of this neglect are severe. Compromised service credentials accounted for a significant portion of major CDN-related breaches in 2025, and the attack surface is expanding as edge functions, serverless architectures, and AI agent systems introduce new categories of non-human actors. This article presents a systematic approach to NHI security at CDN scale, covering workload identity frameworks, attestation mechanisms, credential lifecycle management, and the operational patterns that make machine identity security sustainable across a globally distributed infrastructure.

The Non-Human Identity Problem at CDN Scale

A modern CDN deployment contains a startling diversity of non-human identities. Edge functions authenticate to origin servers using API tokens. Health check services present certificates to verify their legitimacy when probing backend endpoints. Configuration management systems use service accounts to push routing rules to edge nodes. Monitoring agents authenticate to telemetry aggregation services. Terraform automation pipelines hold credentials for infrastructure provisioning. Each of these identities has a lifecycle, a scope of access, and a risk profile that must be managed.

The scale compounds the challenge. A CDN with 300 PoPs, each running 50 distinct services, presents 15,000 workload identities that need provisioning, authentication, authorization, monitoring, and rotation. Traditional identity management approaches that rely on human operators to create, distribute, and rotate credentials simply cannot keep pace. The result is credential sprawl: thousands of API keys scattered across configuration files, environment variables, and deployment scripts, with no centralized inventory and no consistent rotation policy.

This sprawl creates attack surface. A single leaked credential for an inter-PoP communication channel could allow an attacker to inject malicious cache content, redirect traffic, or exfiltrate sensitive request data. The CDN security implications extend beyond the CDN itself, since edge nodes often hold credentials that grant access to customer origin servers and backend APIs.

SPIFFE and SPIRE: Workload Identity for the Edge

The SPIFFE (Secure Production Identity Framework for Everyone) specification addresses the NHI problem by providing a standardized, cryptographic workload identity system. Rather than assigning static credentials to services, SPIFFE assigns each workload a SPIFFE Verifiable Identity Document (SVID) that is cryptographically signed, automatically rotated, and scoped to the specific workload rather than the machine it runs on.

A SPIFFE ID takes the form spiffe://trust-domain/path, where the trust domain identifies the organization and the path identifies the specific workload. In a CDN context, identities might look like:

spiffe://cdn.example.com/edge/pop-fra-01/cache-purge
spiffe://cdn.example.com/edge/pop-nrt-02/origin-fetch
spiffe://cdn.example.com/control-plane/config-push
spiffe://cdn.example.com/monitoring/telemetry-collector

SPIRE (the SPIFFE Runtime Environment) is the reference implementation that handles the critical process of workload attestation: verifying that a workload is what it claims to be before issuing it an SVID. Attestation happens at two levels. Node attestation verifies the identity of the machine itself, using mechanisms like AWS Instance Identity Documents, GCP instance metadata, or bare-metal TPM-based attestation. Workload attestation then verifies the specific process on that node, using properties like the container image hash, Kubernetes service account, or process binary hash.

Deploying SPIRE Across CDN PoPs

SPIRE's architecture maps naturally to CDN topologies. A central SPIRE server cluster (typically three nodes for high availability) runs in the CDN's control plane. Each PoP runs one or more SPIRE agents that communicate with the server cluster over mutual TLS. The agents cache SVIDs locally, so workloads continue to function even if connectivity to the control plane is temporarily interrupted, a critical requirement for edge nodes that may experience intermittent backhaul connectivity.

The SPIRE registration entries define which workloads receive which identities. In a CDN context, these entries typically use Kubernetes selectors (for containerized edge functions) or process-level selectors (for bare-metal services) to match workloads to their intended SPIFFE IDs. The registration entries also define the trust relationships: which identities are authorized to communicate with which other identities, forming the basis of a zero trust service mesh.

NHI Lifecycle Management at Global Scale

Every non-human identity has a lifecycle: creation, distribution, usage, rotation, and revocation. In a CDN operating across dozens of countries and hundreds of PoPs, each stage of this lifecycle must be automated, auditable, and resilient to partial failures.

Credential Creation and Distribution

The creation of NHI credentials should be driven by infrastructure-as-code, with each credential request tied to a specific deployment event. When Terraform provisions a new edge function, it simultaneously registers the workload's identity in SPIRE and defines its authorization scope. This ensures that no workload exists without a managed identity and no identity exists without a corresponding workload.

Distribution is the most operationally challenging stage. Static credentials require secure transport to each PoP where the service runs, typically through a secrets manager that encrypts credentials at rest and in transit. SPIFFE eliminates the distribution problem entirely: the SPIRE agent on each node handles credential issuance locally, so no credential ever traverses the network in a distributable form. The only "distribution" is the SPIRE registration entry, which is a lightweight policy document rather than a sensitive secret.

Rotation and Revocation

Credential rotation in CDN infrastructure must achieve zero downtime, which rules out the simple pattern of "revoke old, issue new." Instead, production systems implement a dual-credential overlap pattern: new credentials are issued and distributed before old credentials are revoked, with a configurable grace period during which both are valid. SPIRE implements this automatically by issuing new SVIDs before the previous ones expire, with configurable TTLs and renewal intervals.

Revocation at CDN scale requires a propagation mechanism that reaches all PoPs within seconds. The edge KV store used for token validation can also store certificate revocation lists or OCSP responses, allowing each PoP to check revocation status locally without contacting a central authority for every authentication decision. This ties into the broader zero trust authentication model, where every service-to-service interaction is verified against the current revocation state.

Service Mesh Identity for CDN Inter-Service Communication

CDN edge nodes run multiple services that must communicate securely: cache management, origin fetching, health checking, configuration updates, and edge function execution. A service mesh provides the infrastructure layer that handles authentication, authorization, and encryption for all inter-service traffic, using workload identities as the foundation.

In a service mesh architecture, each service's sidecar proxy holds the workload's SVID and handles mutual TLS termination. This means application code never touches cryptographic credentials directly, eliminating an entire class of credential-handling bugs. The sidecar validates the peer's SVID against the trust bundle, checks authorization policies, and encrypts the connection, all transparently to the application.

Authorization policies in the service mesh define which identities can communicate with which endpoints. For CDN infrastructure, these policies are typically expressed as allow-lists: the cache-purge service can call the cache-management API, but the telemetry collector cannot. This follows the principle of least privilege that is central to zero trust security models and prevents lateral movement if a single service is compromised.

Cross-PoP Identity Federation

CDN services frequently need to communicate across PoP boundaries. A cache invalidation signal originating at one PoP must be authenticated and authorized at every receiving PoP. SPIFFE's federation mechanism handles this by establishing trust relationships between SPIRE servers in different trust domains, allowing SVIDs issued by one domain to be verified by another.

For CDN architectures where all PoPs belong to the same organization, a single trust domain with a hierarchical SPIFFE ID structure is simpler and sufficient. The path component of the SPIFFE ID encodes the PoP and service identity, enabling fine-grained authorization policies that distinguish between same-PoP and cross-PoP communication. This interoperates with OAuth 2.0 token exchange when edge services need to access external APIs on behalf of end users.

Securing Edge Function Identities

Edge functions present unique NHI challenges. Unlike traditional services that run continuously, edge functions spin up on demand, execute for milliseconds, and terminate. Each invocation needs an identity, but the traditional model of provisioning credentials at deploy time and rotating them periodically does not map well to ephemeral execution environments.

The solution is ambient identity injection, where the edge function runtime provides identity credentials to each function instance through a well-known interface. In SPIFFE-based systems, the SPIRE agent on the edge node pre-fetches SVIDs for registered workloads and serves them through a Unix domain socket (the SPIFFE Workload API). The edge function runtime mounts this socket into the function's execution sandbox, giving each function access to its identity without any credential configuration.

This pattern extends to edge computing workloads beyond simple functions. WebAssembly modules, container-based edge services, and even AI agent processes running at the edge can obtain their identities through the same Workload API, ensuring consistent identity management across all workload types.

Least Privilege for Edge Functions

Each edge function should receive the minimum set of permissions required for its specific task. A function that fetches content from the origin needs authentication credentials for the origin protection layer but should have no access to cache management APIs or configuration stores. The SPIFFE ID's path component encodes this role distinction, and authorization policies enforce the boundary.

In practice, edge function permissions map to a small set of capability profiles: origin-fetch, cache-manage, config-read, telemetry-write, and auth-validate. Each function is assigned one or more profiles through its SPIRE registration entry, and the service mesh enforces these profiles at the network level. This approach works in concert with JWT-based access control, where the function's SVID is exchanged for a scoped JWT when calling APIs that use token-based authentication.

Monitoring and Auditing NHI Activity

The value of NHI security depends on visibility. Every identity issuance, authentication attempt, authorization decision, and credential rotation must be logged and monitored through the same observability platform that handles human access events.

Key monitoring signals for NHI security include:

Authentication failure rates. A spike in failed mTLS handshakes or SVID validation errors at a specific PoP may indicate a compromised node, a misconfigured workload, or an active attack. These alerts should integrate with the incident response pipeline for rapid investigation.

Credential usage patterns. Each NHI should exhibit a predictable usage pattern. A cache-purge service that suddenly begins making origin-fetch requests outside its normal pattern warrants investigation. Anomaly detection models trained on historical NHI behavior can flag these deviations automatically, complementing the rule-based detection in WAF systems.

Rotation compliance. Dashboards should track credential age across all NHIs, flagging any credential that has exceeded its maximum allowed lifetime. SPIFFE-managed SVIDs handle this automatically, but hybrid environments often contain legacy credentials that require manual tracking. The health check system can include credential freshness as a check dimension, marking a PoP as unhealthy if any critical credential has expired.

Threat Detection for Machine Identities

Machine identities face a different threat model than human identities. Credential theft, privilege escalation through service account chaining, and identity impersonation through forged certificates are the primary attack vectors. Detecting these attacks requires correlating NHI activity with infrastructure events.

For example, an SVID issuance for a workload that does not match any deployed container image hash indicates either a misconfiguration or an attempt to obtain a fraudulent identity. Correlating SVID issuance events with deployment logs provides immediate detection. Similarly, a service that authenticates successfully but makes API calls outside its authorized scope may indicate credential theft, which the threat intelligence system should flag for investigation.

The security headers that edge nodes inject into responses can also carry signals about NHI health, allowing end-to-end monitoring of the identity chain from client request through edge processing to origin response.

Migrating from Static Credentials to Workload Identity

Most CDN operators cannot adopt SPIFFE in a single deployment. The migration from static credentials to workload identity is a phased process that must maintain backward compatibility while progressively reducing the attack surface.

Phase 1: Inventory and Classification

The first step is building a complete inventory of all NHIs in the CDN infrastructure. This includes API keys in environment variables, service account credentials in configuration management, certificates in key stores, and any other form of machine credential. Each credential should be classified by criticality (what access it grants), scope (how many PoPs use it), and age (when it was last rotated).

Automated scanning tools can discover credentials embedded in configuration files and deployment scripts. The architecture patterns documentation should capture which services depend on which credentials, creating a dependency map that guides the migration order.

Phase 2: SPIRE Deployment and Shadow Mode

Deploy SPIRE agents to all PoPs while maintaining existing credentials. Register workload entries for critical services and begin issuing SVIDs, but do not enforce SVID-based authentication initially. Instead, run in shadow mode: log whether each request would have been authenticated by SVID, and compare with the existing credential-based authentication result. This reveals misconfigurations and gaps before they cause outages.

Phase 3: Dual Authentication and Cutover

Enable dual authentication: services accept both legacy credentials and SVIDs. Monitor both paths through the observability platform, and when SVID authentication reaches 100% coverage and zero errors for a sustained period, disable legacy credential acceptance. The old credentials can then be revoked.

This phased approach minimizes risk while providing clear milestones and rollback points. The key principle is that no PoP should lose authentication capability at any point during the migration. The TLS configuration at each PoP must support both certificate types during the transition period, and the TLS 1.3 handshake negotiation must accommodate both authentication modes.

Operational Patterns for NHI Security at Scale

Beyond the technical implementation, several operational patterns are essential for sustainable NHI management across CDN infrastructure.

Identity-as-Code. All NHI definitions, including SPIRE registration entries, authorization policies, and credential rotation schedules, should be stored in version control and deployed through the same CI/CD pipeline as infrastructure changes. This ensures auditability and enables peer review of identity changes.

Break-glass procedures. Automated systems occasionally fail, and operators need the ability to manually issue emergency credentials when SPIRE is unavailable. These break-glass procedures should be well-documented, rarely used, and heavily audited. Each emergency credential should have a maximum TTL of four hours and trigger an automatic post-incident review.

Cross-team ownership. NHI security sits at the intersection of platform engineering, security, and operations. A designated NHI owner for each service ensures that credential lifecycle events are tracked and that no identity becomes orphaned when teams reorganize. The multi-factor authentication team and the API gateway team must coordinate on policies that span human and machine identities.

Regular access reviews. Just as human access privileges undergo periodic review, NHI permissions should be audited quarterly. The review checks whether each NHI still needs the permissions it holds, whether any NHIs correspond to decommissioned services, and whether the credential rotation schedule is being followed.

Conclusion

Non-human identities are the silent majority of your CDN's security surface. They outnumber human users, have broader access, change less frequently, and receive less scrutiny. Adopting workload identity through SPIFFE/SPIRE transforms NHI management from an ad-hoc collection of static secrets into a systematic, automated, and auditable identity infrastructure that scales with your edge network. The investment pays dividends across the security stack, from zero trust architecture to incident response, by providing the cryptographic identity foundation that every other security control depends on. Start with the inventory, deploy SPIRE in shadow mode, and migrate incrementally. The goal is not perfection on day one but a consistent trajectory toward a world where no machine credential is long-lived, no service identity is shared, and no access goes unaudited.