TSA Drag

Expanded Definition

TSA Drag is the operational burden that appears when a transition service agreement must remain active because identity assets were never fully separated. It is not just contract delay; it is a sign that service accounts, directory trusts, automation tokens, or shared admin paths still create dependency between the two environments.

In NHI and IAM practice, TSA Drag usually emerges during divestiture, merger, or carve-out work when teams have secured systems but left machine identities behind. The concept is closely related to offboarding, but it is broader because the blocker may be technical, procedural, or governance-related. NIST Cybersecurity Framework 2.0 treats identity and access management as a core governance concern, and TSA Drag is what happens when those controls were not cleanly executed before separation. NHI Management Group also highlights that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why these dependencies persist. For background on how these risks show up across machine identities, see Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0.

The most common misapplication is treating TSA Drag as a procurement or legal scheduling issue, which occurs when the real blocker is unresolved identity coupling.

Examples and Use Cases

Implementing separation rigorously often introduces short-term migration cost, requiring organisations to weigh faster contract closure against the risk of breaking production workflows that still depend on machine identities.

• A carve-out team discovers a shared CI/CD token still deploys to both parent and spun-off environments, so the TSA must stay open until new credentials and pipelines are issued.
• A directory migration cannot close because legacy scripts still authenticate against a central service account, forcing parallel support while access paths are rebuilt.
• A third-party integration remains tied to a parent tenant through API keys, making formal separation impossible until key rotation and endpoint reassignment are completed.
• An acquired business has shared admin roles across cloud subscriptions, so the transition agreement extends while RBAC is redesigned and privileged access is reissued.
• During an exit review, hidden secrets are found in code repositories and config files, a pattern that aligns with the broader secret exposure described in the Ultimate Guide to NHIs.

These cases map to identity separation work described in standards such as the NIST Cybersecurity Framework 2.0, even when the business labels the issue as a transition-services problem.

Why It Matters in NHI Security

TSA Drag matters because every extra day the agreement stays open extends the exposure window for forgotten secrets, overprivileged service accounts, and inherited automation paths. NHI Management Group reports that 97% of NHIs carry excessive privileges and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which shows why unfinished separation is not a minor administrative delay. When the old environment remains partially trusted, attackers may exploit cross-org authentication, stale tokens, or orphaned scripts that were never designed for clean ownership transfer.

From a governance perspective, TSA Drag is often a signal that the organisation lacked inventory, ownership, and revocation discipline before the transaction began. That is why the issue belongs in identity governance and security planning, not just post-close operations. It also aligns with the broader access-control emphasis in the NIST Cybersecurity Framework 2.0 and the NHI lifecycle guidance in Ultimate Guide to NHIs. Organisations typically encounter the cost of TSA Drag only after a carve-out stalls, at which point identity separation becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Certificate Expiry Drag
• Identity Integration Drag
• False Positive Drag