Original announcement source: Security Boulevard / Centrify press release, July 28, 2020.
The Core Problem: Service Account Sprawl in DevOps Environments
Modern DevOps pipelines rely heavily on automation, infrastructure-as-code, and elastic cloud environments. One persistent security friction point in these pipelines is the management of privileged credentials for workloads and services—the non-human accounts that applications use to authenticate to databases, APIs, vaults, and other services.
Traditional approaches to this problem, often called Application-to-Application Password Management (AAPM), improved on hardcoded credentials by moving secrets into a vault. However, they introduced a new operational burden: each application or service still required its own dedicated service account in the vault, complete with a credential and a rotation schedule. In large enterprises, this can mean managing hundreds or thousands of service accounts—slowing down DevOps teams and creating a wide attack surface for adversaries to exploit.
Password vaults were originally designed to manage human administrative logins to servers. Applying them to machine-to-machine authentication at scale creates bottlenecks that developers resent and security teams struggle to govern in fast-moving CI/CD environments.
What Centrify Announced: Delegated Machine Credentials (DMC)
On July 28, 2020, Centrify announced Delegated Machine Credentials (DMC) as part of the Centrify Privileged Access Service (PAS). The feature is designed to address service account sprawl by shifting the unit of identity from the individual application or service to the machine on which those workloads run.
How DMC Works
- Machine enrollment: The Centrify Client enrolls the host machine into the Centrify Platform, giving it a unique machine identity and credential.
- Role-based permissions: The Centrify Platform automatically assigns role-based permissions to the machine and defines which vault APIs that machine is permitted to call.
- Credential delegation: Workloads, applications, containers, and services running on that machine can then delegate the machine’s identity to authenticate to target resources—without needing their own separate service accounts in the vault.
- Scoped, time-limited tokens: Rather than issuing long-lived shared credentials, DMC issues short-lived access tokens scoped to a specific resource and period of time, limiting the window of exposure if a token is compromised.
The result is that one machine identity can serve all the workloads running on it, rather than requiring a separate vault service account for every application, microservice, or container.
The “Federation for Machine Identities” Analogy
Garrett Bekker, principal security analyst at 451 Research (part of S&P Global Market Intelligence), offered a useful conceptual frame for understanding DMC:
“Conceptually, delegated machine credentials can be thought of as ‘federation for machine identities,’ in the sense that rather than applications sharing passwords or secrets directly, the Centrify client can broker a temporary access token between Centrify’s PAS and target resources – applications, service accounts, containers, and APIs. DMC creates a machine identity and issues a scoped token that is only valid for a defined period of time, in lieu of using many service accounts with long-lived credentials that present a greater attack window.”
— Garrett Bekker, Principal Security Analyst, 451 Research / S&P Global Market Intelligence
This federation analogy is instructive for DevSecOps practitioners already familiar with identity federation concepts in human-user SSO: instead of each application managing its own trust relationship with a vault, the machine acts as an intermediary trust anchor, and the Centrify Platform brokers access on its behalf.
Why This Matters for DevSecOps Pipelines
The announcement positions DMC specifically as an enabler of “PAM as a first-class citizen in the CI/CD pipeline.” The practical implications for DevSecOps teams include:
- Reduced manual processes: Eliminating per-application service account creation removes a recurring operational task from already-stretched Ops teams.
- Smaller attack surface: Fewer service accounts with long-lived static credentials means fewer potential entry points for attackers exploiting privileged credential abuse.
- Infrastructure-as-code compatibility: Machine enrollment and permission assignment can be automated, allowing PAM configuration to be managed alongside other infrastructure definitions in tools like Terraform or Ansible—without requiring developers to manually provision vault credentials for each new service.
- Improved developer agility: Developers are no longer required to integrate vault client code into every application that needs to retrieve a credential, reducing friction in the development workflow.
DMC vs. Traditional AAPM: A Comparison
| Dimension | Traditional AAPM | Centrify DMC |
|---|---|---|
| Unit of identity | Each application or service | The host machine |
| Service accounts required | One per application/service | One per machine (shared by all workloads on it) |
| Credential lifespan | Long-lived, rotation-scheduled | Short-lived, scoped tokens |
| Developer integration burden | Vault client code per app | Delegated via Centrify Client on host |
| Infrastructure-as-code fit | Limited; manual provisioning common | Designed for automated, IaC-driven pipelines |
Centrify’s Broader Identity-Centric PAM Position
DMC is part of Centrify’s broader strategy of Identity-Centric Privileged Access Management—a model that emphasizes verifying who (or what) is requesting access, the context of that request, and the risk of the environment, rather than simply managing passwords in a vault. The approach applies least-privilege and just-in-time access principles to both human and machine identities across hybrid and multi-cloud environments.
David McNeely, Chief Strategy Officer at Centrify, summarized the security rationale at the time of the announcement:
“The explosive growth of machine and service accounts in the enterprise is creating a wealth of opportunity for cyber-attackers to sneak into the enterprise. Our infrastructure-as-code approach makes PAM a ‘first class citizen’ in the CI/CD pipeline, eliminating the need for thousands of potential exposure points while increasing agility.”
— David McNeely, Chief Strategy Officer, Centrify
Key Takeaways for DevSecOps Engineers
- If your organization is managing a large number of vault service accounts for automated workloads, DMC-style approaches (whether from Centrify or other vendors) are worth evaluating as a way to reduce that account sprawl.
- Short-lived, scoped tokens are a security improvement over long-lived static credentials for machine-to-machine authentication—a principle also reflected in cloud-native approaches like AWS IAM roles for EC2 instances or Kubernetes service account tokens.
- Embedding PAM tooling into your infrastructure-as-code workflows (rather than bolting it on afterward) reduces the likelihood of credentials being hardcoded or manually managed outside of governance controls.
- Evaluate whether your current AAPM approach requires per-service vault accounts and, if so, what the operational and security cost of that sprawl is at your current scale.
Note: Centrify has undergone corporate changes since this announcement. Readers evaluating Centrify products should verify current product availability and naming directly with the vendor.