Assign ownership by a written rule, not by volunteering. A sensible default: the team that runs it owns it, then the team that depends on it, then the platform or security team holds a temporary claim with a retirement deadline. An unowned unsupported runtime should have a decision date within weeks.
Why orphaned services are the hard cases
The end-of-life items that stay on the list longest are rarely the ones with an active team. They are the batch job someone wrote years ago, the internal tool whose author left, the appliance a vendor installed. The inventory shows a row with a stale runtime and an empty owner field. Nobody is negligent, and still nothing moves, because no one has the authority or the time.
Support dates make this urgent. A runtime moves from active support to security-only to end of life on a published calendar, as the Rails and PHP pages show. When the last phase ends, an orphaned service carries unfixed risk, and that risk belongs to the company whether or not a person is named.
An ownership ladder
- The team that deploys and runs it. Check the deploy logs, on-call rotations and cloud account tags. Whoever pushes to it owns it.
- The team whose product depends on it. Trace callers. A service that feeds a dashboard has a dependent team even if it has no author.
- The team that holds the budget line. Cloud bills and licenses often point to a cost center.
- A designated steward. If steps one to three find nobody, a named person on the platform or security side holds a temporary claim and a retirement clock.
Write the ladder down and publish it. Disputes shrink when the rule exists before the dispute.
The three decisions
Once an owner is named, they choose one of three paths within a deadline you set, for example 30 days for the decision and 90 days for the action.
| Decision | Meaning | Evidence it is done |
|---|---|---|
| Adopt | The team takes ownership and schedules an upgrade | Owner field, ticket, target version and date |
| Retire | The service is no longer needed | Traffic at zero, access removed, resources deleted |
| Isolate | Reduce exposure while a decision is pending | Network limits, least privilege, dated exception |
Isolation is a holding step, not a destination. Upgrade, extend, isolate or retire lays out the full set of options, and a vulnerability exception for end-of-life software gives the record to use.
Finding out whether anyone uses it
Before you spend upgrade effort, check whether the service is still needed. Look at traffic logs, credentials last used, scheduled job history and recent commits to dependent repos. If usage is near zero for a stated period, retiring beats upgrading. Announce the retirement with a date and a way to object, then switch it off in a reversible step before deleting.
Escalation that works
State an escalation path when the owner field is blank on a deadline: first the steward, then the engineering manager of the closest team, then the security lead. Keep each step to a few days. Report orphan counts in the same monthly review as end-of-life dates, so the list shrinks visibly. Which end-of-life component to fix first helps order the queue by exposure.
What to record
- Owner and how they were assigned.
- Decision and decision date.
- Target version or retirement date.
- Exposure and compensating steps in the meantime.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how work is organized and assigned, then picture the owner field filled in for each row.
Where Safeguard fits
Safeguard's asset discovery helps surface services you did not know were running, and its policies and gates give you a place to enforce the rules you set. A free scan is at gold.safeguard.sh/scan.
Quick check
Can security own every orphan?
Only as a temporary steward with a deadline. Lasting ownership should sit with a team that can change the service.
Should I upgrade a service nobody uses?
Check usage first. Retiring it is usually cheaper and removes the risk.
Sources
Last reviewed: 19 October 2026.
