ERP Patching Cadence: How Often Should You Patch?

The operating system and database engine ship security fixes on a frequent, predictable schedule, and they are the layers attackers target first. Delay these for a year and you accumulate known exploitable flaws. The ERP application itself changes more slowly and each cumulative update can alter behaviour, so it justifies fuller testing and a slower rhythm.

A practical baseline for a manufacturer is monthly OS and database patching in a rolling window, quarterly or semi-annual ERP cumulative updates, and an annual review of whether the ERP version is still in vendor support. Many ERP vendors publish a lifecycle policy; running outside mainstream support removes access to security fixes entirely.

Add an emergency path with a target timeline. For a critical remotely exploitable flaw in an internet-facing component, days rather than weeks is the usual expectation. For an internal-only issue with a compensating control, a longer timeline with documented risk acceptance is defensible.

Agree maintenance windows with the plants. A manufacturer running three shifts may have only a few hours on Sunday, which shapes how much you can combine in one change. Prefer smaller, more frequent changes over rare large ones, because the blast radius and the rollback are both simpler.

Reduce downtime with architecture rather than heroics: patch the passive node of a cluster first, use rolling updates across application servers behind a load balancer, and keep the database patch separate from the application upgrade. Each separation makes failures easier to attribute.

Write the rollback before the change, not during an incident. A virtual machine snapshot is quick but does not protect a database whose schema was upgraded and then received new transactions. Define the point after which rollback means restore plus re-keying, and make the go or no-go decision before that point.