Why do identity certifications fail when account data is inconsistent?

Why inconsistent account data breaks identity certification

Identity certifications depend on a stable join between a person and every account or entitlement attributed to that person. When names, employee IDs, source-system keys or lifecycle attributes do not line up, the review cannot reliably aggregate access. The result is either duplicate attestations, missed access, or a reviewer approving the wrong access set for the wrong identity.

That failure is usually not caused by the review step itself. It comes from upstream identity data quality problems, such as duplicate records, stale joins, inconsistent formatting, and attributes that are treated as equivalent when they are not. The certification process can only attest to what it can confidently correlate, so weak identity resolution produces weak assurance.

When this happens, the practical question is not “who clicked approve?” but “did the system know which account belonged to which person?” If the identity graph is unstable, the certification becomes an administrative exercise instead of a control that validates real ownership and access.

How bad matching logic creates false confidence

Certification tools often try to reconcile records from HR, directory services, applications and IAM platforms. If the matching rules are too permissive, two people can be merged and one person’s access can be hidden inside another’s review. If the rules are too strict, the same person can appear multiple times and reviewers may certify a partial view without realising another account exists elsewhere.

This is why deterministic matching matters. Unique identifiers, authoritative source selection and well-defined survivorship rules reduce ambiguity. For a useful treatment of the underlying problem, see the Identity Data Quality and Identity Fabric Guide, which explains why correlation and source-of-truth discipline are prerequisites for dependable identity operations.

In larger environments, the same weakness appears as entitlement drift across multiple systems. A reviewer may see one account record that looks plausible while a second record, created through a different join path, still carries access. Once that split view exists, certification output can look complete without being complete.

What good reconciliation has to establish before review begins

Before any certification campaign starts, the identity system needs to answer a simple question consistently: which records represent the same real-world subject? If the answer is not stable, the review should be treated as incomplete rather than “mostly good enough.” The control objective is not just to display accounts, but to prove that the displayed set is the full set.

Good reconciliation usually depends on a small number of disciplined inputs: unique person identifiers, authoritative attributes, predictable join logic, and exception handling for duplicates or stale records. Where that discipline is missing, remediation should focus on the data model and correlation rules first, because correcting one attestation run without fixing the join logic only preserves the error.

The same principle is explained in NHIMG’s Identity Data Quality and Authoritative Sources Guide, which focuses on authoritative sources per attribute, identity correlation and ownership of remediation. For readers looking at broader governance across people and non-people identities, the Human vs Non-Human Identity guide is useful when shared credentials, delegated access or machine accounts are part of the same access review problem.

Deterministic matching also makes audit evidence more defensible. If a reviewer can show how the identity was resolved, which attributes were authoritative, and how duplicates were handled, the certification is easier to trust and easier to explain when questioned.

Why the control is only as strong as the exception process

Even good matching logic will encounter edge cases. Contractors, rehires, mergers, aliases, renamed accounts and delayed HR updates can all create legitimate mismatches. The maturity test is whether those exceptions are routed to a manual decision path with clear ownership, rather than silently folded into an automated merge or a skipped certification.

That is where identity data governance matters. If exception handling is ad hoc, the process drifts toward convenience and away from control. If the exception queue is visible, measurable and owned, the organisation can separate genuine ambiguity from simple data hygiene issues and reduce the number of reviews that fail for avoidable reasons.

Risk and Threat Considerations

Inconsistent account data does not just weaken administrative review, it creates a security blind spot. Attackers and insiders benefit when one person can be represented by multiple records, because duplicate or stale entries can hide excessive access, delay revocation, or keep an unused account alive long enough to be abused. The same data flaw can also produce false assurance that access has been reviewed when it has not.

Failure mechanism: Broken correlation means the certification tool cannot reliably aggregate all accounts, so reviewers certify a partial identity picture or a merged identity that belongs to more than one subject.

Impact: Excess access may remain undiscovered, orphaned or duplicate accounts can persist, and the organisation may lose confidence in the certification as evidence of actual access control.

Practitioner Guidance

What to verify: Confirm that every certification campaign has a documented authoritative source for person identity, a deterministic matching rule set, and a clear exception path for duplicates and stale records. If reviewers cannot explain how records are joined, the attestation should not be treated as reliable evidence.

Decision rule: If the same person can appear under more than one identifier, treat the data issue as a control defect, not a reviewer mistake. Fix the correlation logic and source quality first; otherwise the next certification will fail in the same way.

Practitioner takeaway: Identity certification is not really failing at review time, it is failing earlier, when the environment cannot prove that one person maps cleanly to one access profile.

Related resources from NHI Mgmt Group

• Guide: Identity Certifications Guide
• Why do Azure AD security controls fail when identity data is inconsistent?
• Why do Triple-A controls fail when identity data is inconsistent?
• Why do governance programmes fail when identity data is siloed?
• Why do GRC programmes fail when identity data is fragmented?