They should usually treat integration cleanup as part of the upgrade decision, not a separate project. If the platform depends on deprecated or manual connections to HR, directory, or cloud systems, the upgrade risk is broader than version numbers. Sequencing should start with the integrations that carry the most identity workflow dependency.
Should the upgrade decision start with the platform or the integrations?
For most teams, the right question is not whether to upgrade first or clean up integrations first, but which dependencies make the upgrade safe. If a platform still relies on brittle HR, directory, or cloud connections, those integrations define the real blast radius. Cleanup should therefore be sequenced with the upgrade work, not deferred until after it.
Why integration debt changes the meaning of an upgrade
An upgrade only looks like a versioning exercise when the platform is loosely coupled. Once the system depends on manual handoffs, deprecated connectors, or undocumented identity flows, the upgrade becomes a workflow and trust exercise as much as a technical one. The highest-risk integrations are usually the ones that create provisioning, deprovisioning, sync, or approval dependencies across systems.
That matters because an upgrade can preserve the wrong behaviour just as easily as it can improve the right behaviour. If the old integration path is the reason access still works, the new version may expose hidden assumptions about timing, data shape, token handling, or account ownership. In practice, integration cleanup is often the work that reveals whether the upgrade is actually feasible.
How to sequence the work without turning it into two separate projects
The practical sequence is to identify the integrations with the most operational and identity workflow dependency, then assess whether they block the upgrade, raise its risk, or simply need adjustment afterward. Direct connections into HR, directory services, cloud IAM, ticketing, and provisioning systems deserve priority because they affect account creation, changes, and revocation.
If an integration is brittle but non-critical, it may be possible to leave it in place temporarily and contain the risk with monitoring. If it is part of the access path itself, it should be treated as upgrade scope. That is especially true where the platform consumes credentials, syncs entitlements, or depends on manual reconciliation to keep records aligned.
Risk and Threat Considerations
Legacy integrations extend the attack and failure surface because they often carry stale permissions, long-lived secrets, and weak ownership boundaries. When those links sit between identity systems and the platform, an upgrade can unintentionally widen exposure or disrupt deprovisioning if the connection model is not cleaned up first.
Failure mechanism: A deprecated or manual integration can continue granting access after the platform changes, or fail open in a way that hides broken provisioning, stale accounts, or inconsistent entitlements. That creates both reliability risk and security risk because the upgrade may succeed technically while the identity workflow silently degrades.
Impact: The result can be orphaned access, delayed revocation, incorrect authorization decisions, and harder incident response if teams can no longer trust the upstream source of truth. In the worst case, an attacker who finds a legacy connector or cached credential inherits a path that the upgrade was supposed to retire.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Long-lived integration credentials and rotation are central to upgrade-related access risk. |
| AC-2 — Account Management | Upgrade sequencing depends on keeping account lifecycle and deprovisioning aligned across systems. | |
| Recommendation — Rotate and retire credentials tied to deprecated integrations before cutover. Validate account lifecycle ownership across every integrated system before changing the platform. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Upgrade timing and integration cleanup both depend on controlled changes to connected systems. |
| Recommendation — Treat integration cleanup as controlled change with documented rollback and verification. | ||
| CIS Controls v8 | CIS-5 — Account Management | Brittle identity integrations often expose account sprawl and stale access paths. |
| Recommendation — Inventory and reconcile accounts and integrations before relying on the upgraded platform. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity management and access permissions are managed, enforced, and reviewed | The question centers on access-dependent integrations that affect upgrade sequencing. |
| Recommendation — Review access dependencies in the integration path before prioritising upgrade timing. | ||
Practitioner Guidance
What to prioritise: Start with the integrations that decide who gets access, who loses access, and which systems are treated as authoritative. Those are the dependencies that most often determine whether an upgrade is safe to execute.
Decision rule: If an integration is required for provisioning, deprovisioning, or entitlement sync, treat it as upgrade-critical and clean it up before or during the migration window. If it is only a reporting or convenience connection, it can usually wait, but only with a documented rollback path and ownership.
What to verify: Confirm that the upgraded platform and its integrations still agree on source of truth, authentication method, and failure handling. The goal is not just “does it connect,” but “does it preserve correct access state under change, retry, and outage conditions.”
Practitioner takeaway: The safest upgrade path is the one that reduces dependency ambiguity first, because brittle integrations are often the real reason upgrades fail or leave behind hidden security debt.
Related resources from NHI Mgmt Group
- How should security teams prioritise NHI remediation in cloud environments?
- Should organisations prioritise external exposure or internal credential governance first?
- How should security teams think about a compromised integration like Drift?
- Should security teams prioritise MFA or privilege cleanup first?