Here’s a scenario that’s become familiar enough that it barely needs a citation anymore: an organization is in the middle of a major transition, merging environments after an acquisition, consolidating tenants, or moving a platform, and attackers get in by compromising a single identity. Sometimes it’s a targeted social-engineering play against one employee; sometimes it’s a credential or access path that nobody had scoped down yet. However they get the foothold, they land in infrastructure the organization didn’t yet fully understand or monitor, move laterally through it, and leave with data they were never supposed to reach. Regulators get involved. Lawsuits follow.
This isn’t drawn from any single company. It’s a composite, because there are now enough examples that no one of them is the point. The specifics vary from case to case, but the shape doesn’t. Organizations don’t usually get breached on a quiet Tuesday in the middle of business as usual. They get breached in the middle of a transition when attack surface is temporarily expanded and the people watching it are stretched the thinnest.
Why migration is different from everyday risk
Most security programs are built around a relatively stable picture of the environment with known users, known devices, known access patterns, and monitoring tuned to notice when something deviates from that baseline. A migration temporarily breaks that picture. For a period that can stretch from weeks to years, an organization runs two directories or tenants at once, often with overlapping or duplicate identities during coexistence, while moving users and devices between them.
Migration tooling itself adds to the exposure. Getting objects moved at scale typically requires standing privileged access, meaning service accounts and automation with broad, persistent rights across both source and target environments, for the duration of the project. That’s exactly the kind of high-value, elevated access attackers look for, and it often exists for longer than anyone intended, because nobody circles back to scope it down once the urgency of the migration has passed.
None of this is a criticism of how migrations get run; some expansion of attack surface and blast radius is unavoidable when you’re merging two environments that were never designed to work together. But it does mean the normal assumptions security teams rely on don’t hold during that window. A newly acquired employee’s account, a legacy system nobody’s fully assessed yet, or a service account granted broad access just for the migration can blend into the noise of a large transition and don’t get scrutinized the way they would in a stable, already-understood environment.
There’s also a more direct exploitation path. During coexistence, security policy is rarely uniform across both environments. Conditional access and MFA enforcement that’s airtight in the target tenant may not yet be fully applied to the source environment, and credentials or trust relationships bridging the two can let an attacker who compromises the weaker side pivot into the stronger one.
Migration tools move objects. They don’t assess identity risk.
Part of the problem is a gap in what migration tooling has traditionally been built to do. Classic migration tools are very good at moving users, groups, and devices from one environment to another. That’s the job, and most of them do it well. What they generally aren’t built to do is evaluate the security condition of what’s being moved. It’s a job for continuous identity risk assessment, the kind that Identity Threat Detection and Response (ITDR) tooling is built for, and it’s rarely applied at the specific moment a migration decision is being made.
That’s a detection coverage gap, not a tooling failure exactly. Migration tools succeed at the object level. Did the account, group, or device move correctly? But they stay blind at the risk level. Should it have moved at all, and what does it expose once it lands? An account that’s been dormant for two years, a user with far more access than their role requires, a device running an outdated or unsupported operating system, a dependency between systems that nobody documented: none of that registers as a migration failure. The migration succeeds. The objects move. The identity risk moves right along with them, and it’s now sitting in the new environment with a fresh coat of legitimacy, because it made it through the migration without anyone flagging it.
What visibility catches before objects move
The fix isn’t more caution or slower migrations; it’s visibility into the environment at the moment decisions are being made, rather than after the fact. Quest Secure Migration, paired with Quest Identity Defense, is designed to surface this kind of visibility before objects move. Specifically, being able to see, before something gets carried into the new environment:
- Stale or dormant accounts and non-human identities. Service accounts and other non-human identities are especially prone to slipping through, since they don’t show up in the HR-driven access reviews that usually catch dormant human accounts.
- Privilege creep and standing administrative access. Access that accumulated over time, or was granted broadly and never scoped back down, and that violates least-privilege principles even if nobody set out to violate them.
- Vulnerable or unmanaged devices, such as outdated or unsupported operating systems or missing security baselines, that haven’t been assessed against the target environment’s security standards.
- Hidden dependencies and lateral movement paths. The kind of undocumented attack path between accounts and systems that graph-based analysis is designed to surface, connecting an ordinary-looking account to a high-value target three hops away.
Catching these things during the migration, while the decision about what to move and how is still being made, is a fundamentally different proposition than catching them afterward, once they’ve been absorbed into daily operations and stopped looking unusual to anyone.
How Secure Migration closes the visibility gap
This is the direction Quest has taken with the integration of Quest Secure Migration and Quest Identity Defense. Rather than treating security review as a separate step that happens, if it happens at all, sometime after the migration is already complete, the integration feeds identity security telemetry directly into the migration workflow. As objects move, it surfaces security findings in context, so teams can flag potential exposures and investigate and remediate risky identities before they are carried into the new environment: stale accounts, excessive privileges, vulnerable devices, hidden dependencies, and other identity risks caught while migration decisions are still being made, rather than discovered later once they have blended into daily operations.
