How do broken ACLs and SID-History create post-migration access problems?

How broken ACL translation turns a migration into access drift

Broken ACL translation is usually the first failure mode because permissions are being copied, rewritten, or inherited across a boundary that does not preserve the original security model perfectly. When translation is lossy, legacy allow entries can become overly broad, inherited rights can expand, and intended denies may stop working. The practical issue is not just “wrong permissions”, it is that the new environment can look valid while silently changing who can read, write, or administer data.

That makes post-migration review harder than a simple before-and-after checklist. Teams need to compare effective access, not just migrated ACL text, because group nesting, inherited permissions, and object ownership can all change the result. In large file systems or directory-heavy migrations, the real control gap is often between the source authorization intent and the destination’s effective permission model.

For the underlying access-control mechanics, see CIS Controls v8 for access control and account management discipline, and ISO/IEC 27001:2022 Information Security Management for access-control governance in a migration programme.

Why SID-History keeps old identities alive after cutover

SID-History exists to preserve access continuity during domain or forest migrations, but it also preserves old security identifiers as a form of backward compatibility. That is useful while both environments still need to function, yet risky once the cutover should be complete. If old SIDs remain trusted too long, users can continue to access resources through an identity path that no longer matches current ownership, role design, or approval records.

The result is a hidden dependency on pre-migration identity state. A user may appear to have clean, current group membership while still carrying access via historical SIDs embedded in tokens or authorization checks. That is why SID-History problems often survive initial testing and only show up later during audit, incident review, or privilege cleanup.

For broader control expectations around identity and authorization, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the access control and audit baseline, while MITRE ATT&CK Enterprise Matrix is useful for thinking about how stale access paths can be abused after migration.

What makes the combination so hard to detect in practice

Broken ACLs and SID-History are dangerous together because they fail in different ways but produce the same operational symptom: access that no longer reflects the intended security model. Broken ACLs can overgrant directly, while SID-History can preserve access indirectly. In both cases, the business sees continued access, but the security team loses confidence that the access is explainable, reviewable, and revocable.

The hardest part is that neither issue necessarily breaks the system. Users still log in, shared drives still open, and critical applications still function. That can mask the exposure until someone compares source and destination entitlements, checks effective access on sensitive objects, or tries to reconcile permissions after an audit finding. In that sense, the migration does not fail loudly, it fails as permission drift.

Where migration risk is concentrated, NIST Cybersecurity Framework 2.0 helps frame governance, access protection, and recovery activities, and NCSC UK Advice and Guidance is a useful reference point for operational control and assurance practices around large infrastructure changes.

Risk and Threat Considerations

These migration failures matter because they create silent overexposure, not just inconvenience. If broad groups inherit permissions they should not have, or if old SIDs remain valid after cutover, attackers and insiders alike can reach data and systems through paths that defenders may no longer realise exist.

Failure mechanism: ACL translation can broaden effective permissions during inheritance or group mapping, while SID-History can keep legacy authorization references accepted long after the target trust model has changed.

Impact: The organisation can end up with unseen access to sensitive data, failed recertification or audit outcomes, and delayed revocation when post-migration cleanup depends on assumptions that are no longer true.

Practitioner Guidance

What to verify: Validate effective access on high-value objects after migration, not just the exported ACLs or the directory entries. Pay special attention to nested group expansion, inherited permissions, and any account that still gains access through historical SIDs.

Decision rule: If an account or group can reach a sensitive resource only because of SID-History, treat that as temporary compatibility debt and remove it on a defined schedule. If the resource is business-critical, confirm the replacement access path before removing the legacy one.

What practitioners underestimate: Audit evidence often looks clean right after cutover because the system is technically functioning. The real question is whether access is explainable from the current identity model, because that is what determines whether the migration created lasting privilege drift.

Practitioner takeaway: The safest migration is the one where every surviving permission can be explained by the new model alone, without relying on old SIDs or translated ACL guesses.

Related resources from NHI Mgmt Group

• What is the difference between rotating a secret and revoking access?
• Why do Oracle ERP environments create SoD and access evidence problems?
• Why do AI agents create governance problems that normal access reviews miss?
• Why do AI assistants create shadow access problems for IAM teams?