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

Accountability usually sits with the platform owner, the application owner, and the security team together. Platform teams control the integration path, application owners understand business impact, and security teams should enforce review, approval, and monitoring. Legacy OAuth apps and unsigned webhooks should be treated as governed assets, not convenience shortcuts, because they can expand trust beyond intended boundaries.

Why This Matters for Security Teams

Unsigned webhooks and legacy OAuth connections are not harmless leftovers. They are still active trust paths that can move data, trigger automation, and bypass newer control expectations. When a security alert points to one of these integrations, the question is less about who clicked approve and more about who allowed an exception to survive. That makes ownership a governance issue, not just an incident response task.

This is where NHI risk becomes visible in day-to-day operations. NHIs often outnumber human identities by 25x to 50x in modern enterprises, and 92% of organisations expose NHIs to third parties, which means stale integrations can persist far beyond their original purpose. NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for controlled access, monitoring, and accountability, but those controls only work if the integration itself is treated as an asset with an owner.

Security teams should expect that legacy OAuth grants and unsigned callbacks will be discovered only after an alert, not during routine review. In practice, many security teams encounter this only after token abuse or unexpected data movement has already occurred, rather than through intentional retirement of the integration.

How It Works in Practice

Accountability usually splits across three functions. The platform owner governs the integration layer, webhook delivery path, and authentication mechanism. The application owner understands what business process depends on the connection and whether it can be removed, replaced, or narrowed. The security team sets the policy for approval, exception handling, logging, and periodic review.

For OAuth connections, the practical issue is that older grants may still possess scopes that are broader than the current business need. For webhooks, unsigned or weakly validated callbacks can be replayed, forged, or redirected if the receiving system accepts them without strong verification. That is why Ultimate Guide to NHIs emphasizes lifecycle control, rotation, and offboarding rather than one-time approval.

• Inventory the integration, including owner, purpose, scopes, secret age, and last use.
• Validate whether the webhook has message signing, timestamp checks, and source allowlisting.
• Review whether the OAuth app still needs the same scopes or can be reissued with narrower access.
• Require a documented decision to keep, replace, or remove the connection after an alert.
• Monitor for token reuse, unusual callback volume, and access from new tenants or IP ranges.

Current guidance suggests treating these connections as governed NHIs, not convenience shortcuts. Incidents such as the Salesloft OAuth token breach and Dropbox Sign breach show how long-lived trust can outlast the original security review. Real-time access decisions should follow current context, not the assumptions made when the integration was first installed. These controls tend to break down when the connection is embedded in a production workflow with no clear business owner, because removal then appears to carry operational risk that no one wants to sign for.

Common Variations and Edge Cases

Tighter integration governance often increases remediation effort, requiring organisations to balance operational continuity against trust reduction. That tradeoff becomes sharper when the webhook or OAuth app supports revenue operations, customer support, or a vendor-managed workflow that cannot be paused easily.

There is no universal standard for this yet, but current guidance suggests that unsigned webhooks should be retired or fronted by a signed, verifiable delivery mechanism wherever possible. Legacy OAuth apps are different: some can be re-authorised with modern scopes, while others must be replaced because the original product no longer supports safer patterns. The right answer depends on whether the integration is still business-critical and whether the platform can prove origin, integrity, and least privilege.

One practical edge case is shared ownership. If the platform team controls the connector, the application team owns the downstream data exposure, and security approved the exception, accountability becomes joint even when the alert is raised by only one team. Another edge case is third-party managed SaaS, where the vendor cannot sign callbacks or narrow scopes quickly. In those environments, a compensating control such as network restriction, token vaulting, or contractual remediation timelines may be needed.

For current visibility and remediation gaps, NHI Mgmt Group research shows that only 5.7% of organisations have full visibility into their service accounts, and 91.6% of secrets remain valid five days after notification. Those findings align with the broader lesson: if the integration is still trusted after the alert, then ownership has not yet translated into action.

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?