In a DevOps world, workloads (applications and services) running on a machine or VM require a service account to authenticate to the vault and check out passwords in an AAPM context (see definition on this page). With the potential for many hundreds or thousands of applications and services, this increase in service accounts carries significant risk by increasing the attack surface for privilege abuse. To combat this, the Centrify vault can grant a machine its own identity, which can then be delegated to trusted local workloads.
When the machine first enrolls in the Centrify Platform, they establish mutual trust. The Centrify Platform creates a unique Delegated Machine Credential, machine identity, and service account for that machine. Local workloads can then piggy-back off that machine identity, leveraging the Delegated Machine Credential to authenticate to the vault, exchanging it for an OAUth2 bearer token it can use for subsequent API calls (e.g., to check out a vaulted secret or password),
Thus, the only service account required is that of the machine itself, versus the hundreds or thousands if each workload were to require its own.