What is a hardware end-of-life policy?

A short written document that defines how your organisation identifies, plans for and retires hardware reaching end-of-life or end-of-support. It sets refresh cycle targets per category, assigns who owns tracking, defines the warning window before a device must be replaced, and specifies how exceptions are approved and documented.

What should an EOL policy include?

At minimum: scope (which assets it covers), definitions (EOL, EOS, EOSL), refresh cycle targets per category, roles and responsibilities, the warning/lead-time window, the review cadence, the exception process, and how EOL data is sourced and recorded. Keep it to one or two pages.

How long should a hardware refresh cycle be?

Common defaults are laptops 4 years, servers 5–6 years, network equipment 6–7 years and firewalls 5 years — but the vendor's published end-of-support date should always override the default when it falls sooner.

IT ops playbooks

Hardware EOL policy template (and how to actually write one)

By Nico De Muynck · Updated July 19, 2026

What this is

A one-page hardware end-of-life policy you can copy, fill in and adopt this week — plus a short explanation of each section so you know what you're signing off on. A policy isn't bureaucracy; it's the thing that turns “we should keep an eye on that” into a rule that survives staff turnover and audits.

Why a written policy beats good intentions

Everyone “knows” old hardware should be replaced. What's missing is a document that says who watches the dates, how far ahead you act, and what counts as too old. Without it, EOL tracking depends on one person remembering — and the day they're on leave is the day a firewall quietly drops out of support. A policy makes the process a system, gives auditors and cyber-insurers something to point at, and settles the “can't we run it one more year?” debate before it starts.

The template — copy and fill in

HARDWARE END-OF-LIFE (EOL) POLICY Owner: [name / role] · Approved: [date] · Review: annually 1. PURPOSE To ensure no hardware runs beyond its vendor support window without a documented, approved decision — protecting security, compliance and uptime. 2. SCOPE Applies to all [servers, network equipment, firewalls, laptops, NAS, and other infrastructure] owned or managed by [organisation]. 3. DEFINITIONS EOL — End of Life: vendor announces the product is retiring. EOS — End of Support: no more patches, TAC or RMA. EOSL — End of Service Life: final support/parts date. (The binding date for planning is EOS/EOSL, not purchase age.) 4. REFRESH CYCLE TARGETS (vendor EOS date overrides if sooner) Laptops / workstations ........ 4 years Servers ....................... 5–6 years Network equipment ............. 6–7 years Firewalls / security appliances 5 years [adjust to your environment] 5. WARNING WINDOW Every asset must be flagged for planned replacement at least [6–12] months before its EOS/EOSL date, so it lands in the next budget cycle — never as an emergency. 6. ROLES & RESPONSIBILITIES [Role] maintains the asset inventory and EOL dates. [Role] reviews the upcoming-EOL list each [quarter]. [Role] approves refresh budgets and exceptions. 7. DATA SOURCE EOL dates are recorded per asset from vendor lifecycle pages and [tracking system], and reviewed [quarterly]. 8. EXCEPTIONS Running an asset past EOS requires written sign-off from [role], a documented risk assessment, a compensating control (e.g. network isolation), and a hard replacement deadline. 9. REVIEW This policy is reviewed annually and after any major infrastructure or compliance change.

Copy the block above into your document system, replace the [bracketed] fields, and get it signed off. One page is plenty — a policy nobody reads protects nobody.

The two sections people get wrong

The warning window (section 5) is the part that actually prevents surprises. A policy that only says “replace at EOL” still lets you get caught, because you find out on the day. Six-to-twelve months of lead time is what turns a refresh into a budgeted line item. The exception process (section 8) is the other one: without it, “let's run it another year” happens informally and undocumented. Force exceptions to be written, risk-assessed and time-boxed, and you kill the slow drift into unsupported infrastructure — which is where the real EOL risks live.

A policy is only as good as the list behind it

Sections 5 and 6 assume someone can produce an accurate “what's reaching EOS in the next 12 months” list on demand. If that list lives in a spreadsheet someone updates by hand, the policy will quietly rot. Pair the policy with an inventory that computes statuses automatically and warns ahead of time — start from our free asset inventory template, and when the manual upkeep gets old, let a tracker do the watching. (For the full method the policy operationalises, see the hardware lifecycle management guide.)

Give your policy a live inventory to stand on.

EOL Tracking holds every asset's EOL date, computes status automatically, and warns you months ahead — so section 5 of your policy runs itself.

Start free — up to 5 assets

No credit card · CSV import for whole fleets