Integration archiving is the administrative action that disables an integration so it no longer receives telemetry or updates. It is a control-plane change, not necessarily a device-side uninstall. Organisations should pair archiving with endpoint removal to prevent stale agents from continuing to exist locally.
Expanded Definition
Integration archiving is a control-plane offboarding action that disables an integration so it stops receiving telemetry, events, or configuration updates. In NHI operations, it is used when an app, connector, or automated workflow is retired, replaced, or no longer authorised, but its local footprint may still exist on an endpoint, runner, or tenant.
Definitions vary across vendors because some platforms treat archiving as a reversible suspension, while others treat it as a lifecycle terminal state. NHI Management Group treats it as an administrative state change, not a guarantee of physical removal, which is why archiving should be paired with endpoint cleanup, token revocation, and ownership reassignment. This distinction matters under the NIST Cybersecurity Framework 2.0 because asset control and identity governance are inseparable once an integration is no longer needed.
The most common misapplication is assuming archived equals removed, which occurs when teams disable the integration record but leave active credentials, webhooks, or installed agents in place.
Examples and Use Cases
Implementing integration archiving rigorously often introduces operational friction, requiring organisations to balance clean governance against the risk of breaking dependent automations that still rely on the old connector.
- A SaaS procurement team decommissions an analytics connector after contract termination, archives the integration record, and then verifies that API keys and webhook subscriptions are revoked.
- A security team responds to a supply-chain incident by archiving a compromised OAuth app and cross-checking whether any local agent, service account, or cached refresh token still exists, similar to patterns seen in the GitHub Repo Breach.
- A platform engineering group retires a CI/CD integration after migration to a new tool and archives it so telemetry stops flowing, while maintaining a documented rollback window for change control.
- An internal audit program archives integrations that no longer have an owner, then flags them for endpoint validation to ensure the control-plane state matches the actual deployment state.
- After a shadow AI app is removed from production, the organisation archives its integration metadata and checks for residual secrets or callbacks, reflecting lessons highlighted in the Vercel Context.ai OAuth Supply Chain Breach.
Why It Matters in NHI Security
Integration archiving is a governance control, but it becomes a security control only when it is paired with revocation, removal, and verification. If teams archive without confirming that tokens, certificates, and agents are gone, they create a false sense of closure and leave an NHI path alive for reuse or abuse. That is especially dangerous in environments where third-party integrations are common and not consistently owned. NHI Management Group has found that 92% of organisations expose NHIs to third parties, which makes offboarding discipline a supply-chain issue, not just an internal housekeeping task.
Archiving also supports auditability by showing when an integration was intentionally taken out of service, who approved it, and what follow-up actions were required. Without that record, incident responders cannot easily distinguish an intentionally retired integration from one that was silently abandoned after a compromise. For lifecycle governance, the practical question is whether the archived state actually means reduced attack surface or merely hidden risk. Organisations typically encounter the cost of incomplete archiving only after a breach review, at which point the term becomes operationally unavoidable to address.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Offboarding and lifecycle state changes govern when an integration should be archived. |
| NIST CSF 2.0 | ID.AM-1 | Asset inventory and lifecycle tracking require retired integrations to be identified and controlled. |
| NIST Zero Trust (SP 800-207) | PR.AC-1 | Zero Trust requires access to stop when an integration is no longer authorised. |
| NIST SP 800-63 | Lifecycle revocation principles apply when machine credentials outlive the integration. | |
| CSA MAESTRO | Agentic systems need explicit retirement states so tools and integrations do not remain callable. |
Treat archived integrations as revoked identities and confirm authenticators are disabled.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
