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