Why is patching edge gear still so ticket-driven?

A lot of this is about ownership and incentives, not whether scripts exist. If security is responsible for approving risk but operations owns deployment, each handoff can turn into a ticket and a delay. Teams may also be judged more harshly for an outage than for taking longer to patch.

Automation needs shared responsibility for the whole path, including testing, rollout decisions, and recovery. Otherwise a ticket is doing coordination work that no team has been set up to own end to end.

Edge systems are not always interchangeable with stateless app instances. Some hold sessions or local state, so replacing or restarting a device can have consequences that a basic rolling deployment does not account for.

That does not rule out automation. It means the rollout needs safeguards suited to the fleet, such as staged deployment, health checks, pause conditions, and a recovery plan. The exact design depends on what the devices do and what disruption is acceptable.

Tickets can still be useful for visibility and accountability. The trouble is when the ticket itself is the deployment mechanism, with a person manually repeating the same steps on every device.

A more useful split is to keep a record of the change while making the repeatable parts automatic. The rollout should also report what was updated, what failed, and where exposure remains, so approval does not mean losing sight of the fleet.

Look beyond the date a patch was released or the date a ticket was closed. Track how long vulnerable systems remain exposed, and whether that status is visible without someone assembling it by hand.

That gives security and operations a shared outcome to work toward. It also helps distinguish a patch that is merely approved from one that has actually reached the systems that need it.