Find Lifecycle Dates Where Vendors Actually Publish Them
A FortiGate 100D hit end-of-support while running a critical branch office, and we discovered this during a firmware update attempt, not from a proactive alert. I was pushing a FortiOS 7.4.3 planning worksheet through our firewall fleet when the 100D showed up as a dead end. No supported firmware path. No clean security advisory coverage. No comfortable answer for why a production branch still depended on it.
My first assumption was wrong: I thought our procurement records would be enough. They had purchase dates, serial numbers, and warranty notes, but they did not have last order dates, end-of-engineering-support dates, or last security fix dates. The real mistake was worse. EoL dates were tracked in a spreadsheet maintained by one engineer, and when that engineer left, the spreadsheet was not updated for 8 months.
That hurt.
I stopped treating lifecycle dates as documentation and started treating them as security data. For our environment, I pulled from vendor lifecycle portals, support contract exports, distributor reports, and direct API feeds where available. Cisco, Fortinet, Aruba, Dell, HPE, Zebra, APC, and VMware each made me handle dates differently, which meant I had to normalize everything before I trusted a single alert.
- Vendor lifecycle API or support portal export
- Procurement system purchase and renewal records
- CMDB model, serial, site, and owner fields
- Firmware inventory from FortiOS 7.4.3 and network scans
- Contract data from our reseller and maintenance provider
My opinion after cleaning the first 500 devices is blunt: if lifecycle data lives outside the asset record, we are pretending we have control.
Build Lifecycle Tracking Into The CMDB
We already had a CMDB, but it was mostly used for ownership, location, and change impact. I extended it instead of buying another dashboard. I added normalized fields for vendor, model, serial, firmware, site criticality, end-of-sale, end-of-support, last-security-fix, replacement project ID, and budget year. I also added source confidence because I learned fast that a reseller spreadsheet and a vendor API do not deserve equal trust.
The integration ran on Ubuntu 22.04 with Python 3.11, scheduled from our automation host, and wrote through the CMDB API after validating model names against our inventory. The fragile part was model matching. One system said “FG-100D,” another said “FortiGate 100D,” and a purchase record said “FG100D-BDL.” I built a small alias table because security automation fails when naming hygiene is treated as someone else’s problem.
Names broke more than APIs did.
from datetime import date
import requests
CMDB_URL = "https://cmdb.internal.example/api/assets"
ALERT_WINDOWS = [365, 180, 90]
def normalize_model(raw_model: str) -> str:
aliases = {
"FG100D-BDL": "FortiGate 100D",
"FG-100D": "FortiGate 100D",
"FORTIGATE-100D": "FortiGate 100D",
}
return aliases.get(raw_model.strip().upper(), raw_model.strip())
def lifecycle_status(asset):
eos = date.fromisoformat(asset["end_of_support"])
days_left = (eos - date.today()).days
return {
"asset_id": asset["id"],
"model": normalize_model(asset["model"]),
"days_to_eos": days_left,
"trigger": next((w for w in ALERT_WINDOWS if days_left <= w), None),
}
def update_cmdb(asset_id, payload, token):
response = requests.patch(
f"{CMDB_URL}/{asset_id}",
json=payload,
headers={"Authorization": f"Bearer {token}"},
timeout=20,
)
response.raise_for_status()
Before automation, 17 of our 500 tracked devices were inside 90 days of end-of-support with no assigned replacement project. After building automated EoL tracking with vendor API integrations and 12-month advance alerts, 0 devices reached EoL without a replacement project already in progress. I do not care how polished a spreadsheet looks; that before-and-after number is the argument.
Trigger Alerts At 12, 6, And 3 Months
I built three alert windows because one alert is just noise with a timestamp. At 12 months, my team opens a replacement project and tags the asset owner. At 6 months, we verify budget, lead time, and migration dependencies. At 3 months, I want an exception signed by the system owner if the device is still not scheduled for replacement. That gave the process teeth.
What I did not expect was how many lifecycle problems were really dependency problems. A switch could be replaced in 2 weeks, but the badge reader hanging off it had a static port requirement nobody wanted to touch. A UPS network card looked trivial until we found that facilities used its SNMP traps for a production line shutdown checklist. Hardware dates exposed undocumented operational coupling.
The alert had to be short.
Our notification payload included asset name, model, site, end-of-support date, business owner, last-seen firmware, replacement project, and the exact reason the alert fired. I sent it to Teams, email, and the ticketing queue, but the ticket was the system of record. Chat messages disappear into scrollback. Tickets force ownership, due dates, and audit history.
I also avoided alerting on every lifecycle milestone. End-of-sale was useful for planning, but end-of-support and last-security-fix drove security decisions. If a firewall, core switch, wireless controller, hypervisor host, or industrial edge gateway lost security fix coverage, I treated that as a risk register event. My opinion: alerts that do not create ownership are decorations.
Connect Lifecycle Data To Budget Planning
The security team did not own every replacement budget, so lifecycle tracking had to speak finance without becoming a finance tool. I added estimated replacement cost, preferred replacement model, budget year, and capital-versus-operating classification to the CMDB. For our FortiGate replacements, I mapped branch firewalls to current equivalent models and added implementation labor because hardware cost alone always undercounts the real work.
You may also find this useful: Check out our guide on Python Network Config Backup: Automating Multi-Vendor Device Snapshots for more practical tips.
This changed our annual budget conversation. Instead of saying we had “some aging network gear,” I walked in with 43 devices requiring replacement in FY2027, 18 of them security-sensitive, and 6 tied to production network zones. The exact number mattered. It made delay visible, and it made deferral a documented risk decision instead of a quiet operational drift.
Finance likes dates.
We also built a replacement runway by site criticality. A low-risk office printer switch could wait behind a plant firewall. A wireless controller serving handheld scanners in the warehouse could not. I used simple scoring: exposure, business criticality, compensating controls, vendor support status, and implementation lead time. I did not need a complicated model; I needed a repeatable one my team could defend during audit.
The strongest budget benefit was removing surprise. A device approaching end-of-life stopped being a panic ticket and became a scheduled project with a purchase request, implementation window, and rollback plan. My opinion: lifecycle automation earns trust when it makes next year’s spend boring.
Keep The Process Owned By Security
I do not think hardware lifecycle tracking belongs only to infrastructure operations. Operations owns replacement work, but security owns the risk created when unsupported hardware remains connected to production networks. In our manufacturing facility, that distinction matters because plant uptime pressure can normalize old equipment for years unless someone keeps security risk visible.
I built a monthly review around exceptions. We looked at every device inside the 12-month window, every device missing lifecycle data, every vendor source that failed refresh, and every replacement project without a target date. Missing data got the same attention as bad data because unknown support status is not neutral. It is unmanaged risk.
Unknown is a status.
The process now runs with Python 3.11 on Ubuntu 22.04, writes to the CMDB, alerts at 365, 180, and 90 days, and creates tickets before procurement lead time becomes a crisis. FortiOS 7.4.3 planning no longer depends on someone remembering to open a spreadsheet. When a model ages out, my team sees it early enough to design, budget, test, and replace it without gambling on unsupported firmware.
I still keep a human review in the loop because vendor data changes, support contracts get renewed, and replacement projects slip. Automation gives me coverage, not absolution. My opinion is firm: hardware lifecycle tracking is a security control because unsupported devices eventually become unpatchable infrastructure, and unpatchable infrastructure becomes an incident waiting for a maintenance window.