When a creator leaves, a low-code app either stops working because its connection was tied to their account, or keeps running with their credentials and no owner. Both outcomes are risks. Before the leaving date, reassign the app, move its connections to a service identity, or retire it.
Why it goes wrong
OWASP's Asset Management Failures (CD-SEC-09) describes citizen-built apps that are forgotten or abandoned while still active. Useful apps also spread, so usage and dependency grow without the business continuity measures expected of standard systems, such as a designated owner, IT monitoring or an SLA. Orphaned apps fall outside monitoring and patching, and an attacker who exploits one inherits its established, unreviewed permissions.
Embedded credentials add a second problem. If the app runs as the creator, disabling the account breaks the app, and keeping the account alive keeps unreviewed access in place.
A leaver checklist for low-code apps
- List apps owned. Query each platform, or use your registry, for apps the person created or administers.
- List connections owned. Note any tied to their personal identity.
- Classify each app. Keep, hand over, convert or retire.
- Hand over. Name a new owner who accepts responsibility and gets access to the app settings.
- Convert. Replace the personal connection with a service identity of narrow scope, test, then remove the old one.
- Retire. Disable the app, wait a defined period, then delete it and revoke its grants at the source.
- Update the registry and the review date.
Decision table
| Situation | Action |
|---|---|
| Personal productivity flow, no other users | Retire |
| Team app, active use, personal login embedded | Convert to service identity, hand over |
| Sensitive data app | Hand over to a named owner and schedule a review within the month |
| No one knows what it does | Pause, watch for complaints, then retire |
Timing
Do the review before the last day, not after. Access removal at exit should include platform admin roles, because someone with maker rights can rebuild a flow elsewhere.
Prevent the problem
- Require an owner and a backup owner in the registry.
- Prefer service identities over personal logins from the start.
- Add low-code platforms to the standard offboarding checklist, next to email and source control. See SaaS offboarding checklist for a departing employee.
- Send a quarterly list of apps with owners who no longer work here.
A short example
An operations analyst builds a flow that copies new orders into a finance spreadsheet, using their own login for both systems. They move teams and later leave. If IT disables the account, orders stop syncing and finance notices a week later. If nobody disables it, the flow keeps running on a former employee's access. The better path: before the move, switch the flow to a service identity with read access to orders and write access to one sheet, name a new owner and record the change.
Where Safeguard fits
Safeguard's agent identity capability applies the same ownership idea to AI agents, and asset discovery helps engineers find repos and services nobody tracks. Low-code platform apps are listed through each platform's admin tools. Free scan: https://gold.safeguard.sh/scan.
Quick check
Should we delete the app straight away?
Usually no. Disable first, wait, and check that nothing depends on it, then delete and revoke grants.
Is a backup owner really needed?
Yes. It avoids an orphaned app when the owner is away or leaves.
Sources
Last reviewed: 19 October 2026.
