Zombie connections are stored credentials in low-code platforms that outlive their purpose: long-lived, broadly scoped and hard to monitor. Find them by exporting every connection with its owner, scope and last use, then retire the unused ones in stages, starting with the broadest.
How they form
OWASP describes this under Authorization Misuse (CD-SEC-03). Connectors and embedded authentication make setup fast. OAuth flows, refresh tokens and API keys are stored or shared across apps and persist well beyond their intended lifecycle. Scopes are often defined too broadly for the sake of convenience. Over time this leaves an ecosystem of abandoned connections that are long-lived, broadly scoped and challenging to revoke.
OWASP's scenario: an analyst grants an app read and write access to all data in a customer system instead of just sales reports. The platform keeps the refresh token indefinitely, and a teammate clones the app, which reuses the connection.
Signs you have them
- Connections named after people who have left.
- Connections with no recorded app or purpose.
- Scopes that say all data or full access.
- Clones of an app sharing one connection.
- No successful run in months, yet the credential is still valid.
A staged retirement plan
- Export. Pull every connection with owner, target system, scope and last used date.
- Rank. Put broad scopes and personal identities first.
- Ask. Send each owner a short message: keep, replace or retire, with a date.
- Disable before delete. Pause the connection, wait a defined period, and watch for breakage.
- Revoke at the source. Removing a connection in the platform may not revoke the token in the target service, so revoke there too.
- Record. Note the decision in the inventory.
Prevention OWASP lists
- Disable or monitor implicitly shared connections.
- Apply least privilege to environments that can hold shared connections.
- Monitor platforms for over-shared connections.
- Educate business users on how connection sharing relates to credential sharing.
- Re-authenticate connections regularly so OAuth tokens are refreshed deliberately.
- Review the scope an app requires and keep it minimal.
A simple scope review table
| Question | Healthy answer |
|---|---|
| Does the scope match the app's one job? | Yes, read only where possible |
| Is it tied to a person? | No, to a service identity |
| Is it shared by more than one app? | No |
| Is there a recorded owner and review date? | Yes |
Related reading: one connection per automation explains why splitting connections limits the damage.
Making it routine
A one-off clean-up decays. Add a recurring task: each quarter, export connections, compare them with the registry and send owners a keep or retire prompt. Track how many connections have no owner, how many use personal identities and how many have broad scopes. If those three numbers fall over time, the process is working. If they do not, look at whether owners receive the prompt and whether retiring a connection is easy enough that people do it.
Where Safeguard fits
Safeguard's compliance and evidence automation can help you keep a record of access reviews you perform, though the review itself starts in each platform's admin console. For code your teams write, try the free scan at https://gold.safeguard.sh/scan.
Quick check
Does deleting a connection revoke the token?
Not necessarily. Also revoke the grant in the connected service, then confirm access is gone.
How often should connections be reviewed?
Quarterly for sensitive apps is a reasonable start. Adjust based on how many connections you find.
Sources
Last reviewed: 19 October 2026.
