The destination model quickly diverges from the source as users change, groups are reorganized, and policies are updated. Over time, a person may retain access through OneLake even after the source platform would have removed it. That is an entitlement drift problem, not just an administrative inconvenience.
Why This Matters for Security Teams
When permissions are copied once and never resynchronised, access control stops reflecting the source of truth. That creates entitlement drift, which is especially dangerous in environments where joiners, movers, and leavers change frequently or where inherited group membership drives downstream access. The risk is not limited to overexposure; stale permissions also weaken auditability, complicate incident response, and make compliance evidence unreliable.
Security teams often miss this because a copied model looks stable at first. The access review may pass, the application may still function, and the problem only becomes visible when someone who should have been removed can still reach data or administrative actions. That is why control design matters more than administrative convenience. Guidance in the NIST SP 800-53 Rev 5 Security and Privacy Controls aligns with this problem through continuous access and configuration discipline rather than one-time approval.
In practice, many security teams encounter entitlement drift only after a user retention review, an audit finding, or a misuse investigation, rather than through intentional access governance.
How It Works in Practice
Copied permissions usually fail because they freeze a moment in time. The source system may later change role mappings, remove a group, update policy conditions, or replace direct grants with more granular controls. If the destination system does not resync, it keeps the old entitlements and accumulates exceptions that no longer match business intent. This is common in hybrid estates, tenant migrations, and analytics platforms where access is replicated into secondary stores or workspaces.
The operational question is whether the copied permissions are merely a bootstrap, or whether they are expected to remain authoritative. Current guidance suggests they should not be treated as authoritative unless there is a documented reconciliation process. Mature implementation usually includes:
- Scheduled comparison between source and destination entitlements
- Automated removal of permissions that no longer exist upstream
- Explicit handling for exceptions, service accounts, and break-glass access
- Approval workflows for local overrides so drift is visible and reviewable
- Logging that ties every retained permission back to a business or technical owner
This is also where identity governance intersects with Non-Human Identity control. If a copied permission set includes service identities, tokens, or application access, the same drift problem can expand into machine access pathways and make the blast radius much larger. The OWASP Non-Human Identity Top 10 is useful here because it highlights how unmanaged machine credentials and inconsistent lifecycle controls create lasting exposure.
These controls tend to break down when the source system has no reliable canonical owner or when downstream platforms allow local edits without reconciliation, because no one can prove which permission set is current.
Common Variations and Edge Cases
Tighter resynchronisation often increases operational overhead, requiring organisations to balance access freshness against change-management friction. That tradeoff is real in environments with legacy applications, delegated administration, or business processes that depend on local exceptions.
There is no universal standard for this yet, but current guidance suggests a few edge cases need special handling. Service accounts may need different resync logic than human users because their access is often tied to automation schedules rather than HR events. Offline or intermittently connected systems may need delayed reconciliation, which means the organisation must explicitly define acceptable staleness. In mergers, migrations, or platform splits, copied permissions are sometimes used intentionally as a temporary bridge, but they should carry an expiry date and a reconciliation owner.
Another common failure mode is assuming that inherited access will clean itself up after upstream changes. In reality, downstream systems often preserve explicit grants that survive group reorganization, policy changes, or access-model redesign. That is why entitlement reviews should test both direct and inherited permissions, not just visible role assignments. For security programs that need a control baseline, NIST control families around access enforcement and system monitoring remain the practical anchor, while the identity team should document where local autonomy is allowed and where resync is mandatory.
Where copied access is used as a permanent substitute for lifecycle management, the control model usually collapses during audits, platform migrations, or any event that changes the source permission structure faster than the destination can follow.
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 CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Copied access must stay aligned to an approved identity source and access model. |
| OWASP Non-Human Identity Top 10 | Copied permissions can extend into non-human identities and service credentials. | |
| NIST SP 800-53 Rev 5 | AC-2 | Account lifecycle management addresses stale access after user or group changes. |
Keep the source of truth authoritative and reconcile downstream access against it on a fixed schedule.
