Subscribe to the Non-Human & AI Identity Journal

PAC Merging

PAC merging is the process by which a domain controller combines Privileged Attribute Certificate data from related account objects during authentication. It is intended to preserve service access during legitimate migration, but it becomes dangerous if an attacker can choose the predecessor account and inherit a wider set of privileges.

Expanded Definition

PAC merging is a directory authentication behavior that combines Privileged Attribute Certificate data from related account objects so a service does not break during a planned migration or account transition. In identity systems that support it, the merged attributes influence what the authenticating principal can access, which means the effective privilege set may be broader than the current account alone would suggest.

In NHI operations, the key issue is not the merge itself but the trust boundary around predecessor and successor accounts. PAC merging can be legitimate when it preserves continuity during controlled identity lifecycle changes, yet it becomes risky when account lineage is unclear, stale objects remain reachable, or privilege inheritance is not tightly constrained. This is why NHI Management Group treats it as an identity governance concern, not just an authentication detail. For broader control context, the NIST Cybersecurity Framework 2.0 places emphasis on access control and identity governance that help limit privilege sprawl.

Definitions vary across vendors because some products document PAC behavior as an implementation detail while others expose it as an administrative setting. The most common misapplication is treating PAC merging as harmless default functionality, which occurs when migration accounts inherit privileges from old objects that were never decommissioned.

Examples and Use Cases

Implementing PAC merging rigorously often introduces migration overhead, requiring organisations to weigh service continuity against the risk of inherited privilege.

  • A file service is moved to a new service account, and PAC data from the predecessor is merged so scheduled jobs continue running without immediate reconfiguration.
  • A legacy application depends on nested account history during a domain transition, so merged attributes preserve access while the team phases out the old identity.
  • An attacker who compromises an abandoned predecessor account can exploit the merge path to obtain broader privileges than the active account should have had, echoing the excessive-privilege patterns described in the Ultimate Guide to NHIs.
  • A security team validates that only approved migrations can trigger attribute inheritance and uses zero trust controls to ensure every access decision is re-evaluated, consistent with guidance in NIST Cybersecurity Framework 2.0.
  • During account consolidation, administrators audit historical objects to ensure no stale delegation paths remain available for unintended privilege carryover.

PAC merging is most useful when identity continuity matters more than immediate refactoring, but it should be paired with strict lifecycle review, explicit approval, and rollback planning.

Why It Matters in NHI Security

PAC merging matters because NHI compromise often succeeds through identity lineage, not just password theft. When merged attributes are left unchecked, a single service account or machine identity can quietly accumulate privileges across migrations, decommissioned objects, and forgotten delegation paths. That creates an especially dangerous condition in environments where visibility is already limited; NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, which makes hidden privilege inheritance far harder to spot.

For practitioners, the control problem is to prove which account lineage is authoritative, which attributes are allowed to merge, and when inherited permissions must be stripped. That means logging migrations, reviewing predecessor objects, and testing whether access survives account retirement for the wrong reasons. In zero trust programs, PAC merging becomes a governance test for whether identity history is being used safely or abused as an escalation channel. Organisations typically encounter the consequences only after an incident review reveals that a migrated identity retained unexpected access, at which point PAC merging becomes operationally unavoidable to address.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-02 Covers NHI secret and privilege exposure risks tied to inherited access paths.
NIST Zero Trust (SP 800-207) AC-6 Zero trust least-privilege principles apply when merged attributes can widen effective access.
NIST CSF 2.0 PR.AC-4 Identity and access governance is required to control account lineage and privilege inheritance.

Review merged identity privileges and retire predecessor accounts before access inheritance persists.