Who is accountable when unsigned webhooks or legacy OAuth connections are left in place after a security alert?

Accountability for Dormant Integrations After an Alert

When unsigned webhooks or legacy OAuth connections remain in place after a security alert, the accountability question is really about who owns the trust boundary. Platform teams typically own the integration mechanism, application owners own the business use and acceptable risk, and security teams own the review process that should force timely action. If one of those roles is missing, the control failure is usually not technical ambiguity but incomplete governance over a live access path.

Unsigned webhooks matter because they can accept traffic without cryptographic assurance of origin, while legacy OAuth connections often keep delegated access active long after the original business need has changed. That combination turns a convenience integration into a persistent trust channel. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames accountability around access enforcement, system monitoring, and configuration governance rather than treating integrations as informal exceptions.

In practice, many security teams discover that nobody feels responsible for removing stale integrations until the alert has already been triaged and the trust path is still open.

How Governance Breaks Down in Practice

The operational problem is usually not that teams disagree on the alert. It is that each team sees only part of the lifecycle. Platform teams may create or maintain the webhook endpoint, integration service, or OAuth registration. Application teams may be the only ones who understand whether the connection still supports a critical workflow. Security teams may receive the alert, but unless they have a defined approval and exception process, they can only recommend action rather than ensure it happens.

That division of labour becomes risky when the integration is no longer actively used but still trusted. A legacy OAuth app can retain scopes that are broader than current need, and an unsigned webhook can remain reachable even when the originating system has changed ownership or security posture. The real governance failure is allowing trust to persist without a current owner who can attest to its purpose, scope, and monitoring state.

Good practice is to treat these connections as governed assets with a named owner, an expiry or review date, and an explicit reauthorization path after any alert. That means the alert should trigger not only investigation, but also an ownership check, scope review, and removal decision if the business case cannot be revalidated. Where the connection supports a core workflow, the team should be able to prove why the access remains necessary and what compensating controls are in place. Where that proof is missing, the safest answer is to disable the path until it is re-approved.

• Confirm which team can actually approve removal or renewal of the connection.
• Check whether the integration still has business value or is simply tolerated debt.
• Verify whether the current scopes, signing method, and monitoring match today’s risk appetite.

This guidance breaks down when organisations cannot identify the system of record for integrations or when ownership has been spread across several teams without an explicit approval workflow.

Where Stale Integrations Create the Most Risk

Tighter integration governance often increases operational friction, so organisations have to balance fast delivery against the cost of unmanaged trust. The edge cases are usually legacy systems, third-party connectors, and business-critical automations that were never designed with modern review cycles. In those environments, the question is not whether every old integration should be removed immediately, but whether the exception is still defensible and time-bound.

There is also a difference between signed and unsigned mechanisms that matters for accountability. Signed webhooks provide stronger origin assurance, but they still require ownership, logging, and rotation discipline. Legacy OAuth connections are often more exposed because delegated access can survive long after the user, application, or vendor relationship has changed. This is where governance and technical control meet: a connection can be technically functional while being organisationally unjustified.

For teams handling mergers, vendor churn, or platform migrations, the hardest cases are the ones where nobody wants to own the decommissioning work because the service appears to be “still working.” That is exactly when dormant access paths become difficult to see and easy to inherit. In practice, the safest approach is to classify any unreviewed integration left after an alert as a privileged exception until someone can prove it is still needed.

Related resources from NHI Mgmt Group

• Who is accountable when legacy VPN infrastructure remains in place after exposure risks are known?
• Who is accountable when legacy credentials are left in place and later abused?
• Who is accountable when security gaps in guest systems are left unremediated after pentesting?
• How should security teams prioritise NHI remediation in cloud environments?