Asset lifecycle management

Introduction

Tracking assets throughout their lifecycle helps your organisation carry out system hardening, apply patches, and safely decommission outdated assets.

The first step is understanding your environment. You can’t put good security controls in place unless you know what’s in your environment, their importance and how it works.

Asset lifecycle management helps you keep an accurate, up to date view of your environment. It tracks your software and hardware through each key stage – from purchase or development, through maintenance, to decommissioning.

A critical part of this lifecycle is knowing when a system becomes legacy. Legacy systems are ones that a vendor no longer supports, or that your organisation no longer maintains.

It’s also important to understand your organisation’s supply chain and the risks it brings. A targeted attack on one of your suppliers can affect your systems too. Including supply chain assets in your lifecycle management helps reduce that risk.

Many of the incidents – here and overseas – are caused by a lack of maintenance. Systems are left unpatched or un-hardened because they’ve been forgotten, sometimes long after their end-of-support date. Often, organisations only realise these systems are still in use after they’ve been hit with ransomware and part of their network goes down.

What is asset lifecycle management?

Asset lifecycle management helps you keep track of your hardware and software, so your view of your environment stays accurate and up to date. It follows each item from when it’s bought or developed, through its maintenance, to when it’s no longer used.

How to create an asset lifecycle

Keeping track of your physical and digital assets is an important step of maintaining a secure environment.

Asset lifecycle management includes three key stages: purchase and development, maintenance, and decommissioning. Here’s how each stage should be planned.

Purchase and development

Record new assets

The asset lifecycle starts by recording new hardware and software assets. Having this process in place from the beginning helps ensure no new assets fall through the gaps. Once this is set up, you can move on to identifying and recording existing assets.

Identifying existing assets can be a challenge. For help including them in your asset lifecycle, see the next section: How to identify existing assets.

Creating a new process for recording assets takes input from several teams across your organisation. It’s important that the tools and processes you use work for everyone involved.

For each asset, record the following details:

type of asset,
asset owner, or the person responsible for maintaining it,
vendor, developer, or person supplying patches,
the asset’s location – physical and network (or digital),
a unique ID or serial number to identify physical assets,
the system the asset supports,
the asset’s end-of-life or end-of-support date (if set), and
software versions and enabled services.

To make sure you’re including all the relevant IT assets, check you’ve covered:

user devices such as desktops, mobile phones, tablets, and laptops,
peripheral equipment like keyboards, docking stations, printers, fax machines, and scanners,
network equipment such as routers, switches, and access cameras,
infrastructure including locally hosted and cloud-hosted servers, backup systems, and supporting network components, and
software including types of software used and any licenses.

Harden new assets

Once an asset is recorded, it should be hardened before use. This is a good way to build other security controls into the asset’s lifecycle. Hardening means:

removing or updating default accounts or passwords,
disabling unused services and closing ports, and
updating the software to the latest release.

See our other critical control guides for details on hardening assets.

See all the critical controls

Maintenance

Link your patching and vulnerability management processes

Keeping an up-to-date asset record helps make sure all your assets are patched – and that there are no unknown systems on your network.

Your asset list can show where patches should come from and who in your organisation is responsible for applying them. As new assets are added, make sure they’re included in your existing patching processes. By cross-referencing against your asset list, you can confirm that all systems are covered.

Understanding the maintenance requirements for your assets is important. Some vendors will require agreements in place to provide continued software updates. Staying connected with vendor updates is also crucial to receive timely updates for critical security and software maintenance updates.

Create a patching process

A good vulnerability management process helps your organisation find unpatched or insecure assets on your network. Your asset records are a valuable part of this – they help confirm whether the assets found belong to you, or whether further investigation is needed.

Patching

Plan for legacy systems

Unsupported assets need to be replaced as soon as possible to reduce the risk to your environment. Vendors usually announce end-of-support dates well in advance to give you time to plan a migration. Once announced, these dates should be recorded and shared so your organisation can assess the systems affected and decide how to mitigate the risk or migrate to a supported option.

For more on this, see the sections below about identifying, managing, and mitigating legacy systems.

Decommissioning

Remove assets

When an asset reaches the end of its life, follow a decommissioning process to safely remove it from your environment. Every asset is different, but here are some key points to consider.

Make sure the asset is no longer in use. Before decommissioning any asset, make sure all required functions are transferred to other assets.
Review your data retention requirements. Before disposing of an asset, check any data retention standards that apply to your organisation. Make sure data can still be restored from a backup, even if the original asset is gone.
Turn off the asset and remove its dependencies. Assets often rely on other components to function – such as DNS records, firewall rules, physical wiring, or even other assets. Power down physical assets and remove any remaining digital traces.
Secure any brand-related or public dependencies. Some dependencies, like domain names and static IP addresses, may also be used by others. These are often linked directly to your organisation and signal trust to the public. If you no longer need them, don’t delete them – redirect them to your new assets. Staying in control of these resources helps prevent attackers from reusing them to impersonate you or target others.

Dispose of assets

Once you’ve removed an asset from your environment, you can plan how to dispose of any related physical hardware. When disposing of devices, it’s important to make sure no organisational data is left behind. To do this, follow these key steps.

Sanitise the device or securely remove all data. This is especially important for any assets that held sensitive information. If you’re unsure what data was stored on the device, it’s safer to sanitise it.
Decide whether to destroy or sell the device. If you plan to sell it, be confident that all data has been completely removed. If the asset contained sensitive data, it may be safer to destroy it. You can contact a professional asset destruction company to help ensure it’s disposed of securely.

If your organisation plans to re-use or repurpose the device internally, it should still be sanitised first. That way you know you’re starting with a clean asset.

How to identify existing assets

Understanding what assets are in your environment is a fundamental part of any security programme. You can’t properly assess risks or apply effective controls if you don’t know what’s running in your environment.

Keeping an up-to-date asset list is harder than it sounds. Many organisations are compromised through systems they forgot about, failed to decommission properly, or that were set up unofficially by users – also known as shadow IT.

Including existing assets in your lifecycle

Assets can be physical or virtual. Both types need to be managed properly, though each comes with different considerations. Once you have a lifecycle and processes in place for managing assets, you can start including your existing ones – turning them from unknown to recorded.

To identify assets, begin with a network scan and a physical inventory of systems. Old purchase records can also help. Every asset you identify must either be recorded with the right details or removed and disposed of.

Maintaining your asset list is an ongoing task. Consider using regular network scans to detect systems, applications including cloud components that aren’t on your list. These may have been deployed without following proper processes and should be investigated.

Audit your existing assets

After recording your existing assets, check with the asset owners to confirm their current hardening status. If these assets have been in use for some time, they may not have been hardened when deployed. This may also include legacy assets or assets approaching their end-of-service or end-of-license agreements.

Your organisation’s risk profile may also have changed. A configuration that was acceptable in the past may no longer meet your current security requirements.

How to identify legacy systems

Legacy systems are older systems that either no longer receive support from a vendor or are no longer required or maintained by the organisation. They include software that’s unsupported or at the end of its life, as well as devices that can’t be updated or patched.

Here are the steps to help you identify legacy systems in your environment, so you can assess the risk and plan for their management and mitigation.

Understand your environment

Start by identifying all components in your environment, including the versions they’re running.

This means checking all software and devices, such as:

servers,
applications,
network devices,
office devices, and
staff-owned devices (BYOD).

Full network scans can help you uncover systems that aren’t documented or known to your IT and information security teams – sometimes called ‘shadow IT.’ Scanning can also help confirm which versions are installed.

Once you have a complete list, identify which components are parts of legacy systems. These may include:

components no longer supported by the vendor or that have reached end-of-life, and
components that haven’t been patched or no longer required by your organisation.

Compare the versions you’re running against the vendor’s current supported versions. If a component can no longer be updated or unsupported, the system it belongs to is considered legacy.

You should regularly scan your network for vulnerable and unsupported software. Build this into existing processes, such as:

vulnerability management,
software lifecycle management, and
device lifecycle management.

Understand the risk and context

Look at each legacy system in both a technical and business context. Even a minor issue can reduce the overall security of your environment – sometimes in ways that aren’t obvious. For example, a small application running on a Windows Server 2003 machine may seem low risk. But if that server is part of your domain, it may require the use of outdated encryption protocols – putting the rest of your environment at risk, including non-legacy systems.

Now think about what the system does and why it matters:

What information is stored in the system?
What business processes rely on it?
What could happen if that data were leaked or if the system was disrupted?
Could your organisation continue to operate without it?

Once you’ve identified all your legacy systems – and understand both their technical and business risks – you can plan how and when to replace them.

Replacing a legacy system takes time. Until then, use risk management and mitigation strategies to reduce exposure.

How to manage legacy systems

Legacy systems carry known risks, but there are practical ways to reduce them – especially when you can’t replace the system right away. Restricting access and increasing monitoring are key. The steps below are good practice for all systems, but they’re especially important for legacy infrastructure.

Set a baseline and monitor activity

Establish normal behaviour for the system so you can detect anything unusual. Investigate any irregular activity – it could be a sign of a breach.

Prepare for disruption or breach

Know which processes and data would be affected if the system failed or was breached. Plan your response ahead of time. The more difficult it would be to recover, the higher the priority should be to replace the system.

Keep spare parts

Many legacy systems rely on hardware that’s no longer supported. Plan for how you’ll handle a hardware failure. Keeping spares on hand can reduce stress and speed up recovery. In some cases, replacement parts can take days or weeks to arrive – especially if sourced from overseas.

Ask the vendor about extended support

You may be able to pay for extended support from the vendor – but this is usually temporary and can be expensive. It won’t fix the root issue. In some cases:

only critical security updates are provided,
some vulnerabilities may still go unpatched,
the cost may increase over time, and
the vendor may eventually stop offering support.

How to mitigate legacy systems

Here are some short-term mitigation options. These steps can help you limit vulnerabilities and prevent or detect incidents — until the system is fully supported or decommissioned.

Option 1: Remove or replace the system

Legacy systems are, by definition, outdated and vulnerable. The safest option is to stop using them or remove them from your network.

This may take time or cost more than other options – but it reduces your exposure to known and unknown vulnerabilities. Even during a replacement project, the legacy system may need to stay online. If so, you must restrict access while it’s still in use.

Option 2: Restrict access to the system

Physically isolate it

If a system is only needed by one person or team, move it off the network and onto a standalone device. This reduces the chance of remote compromise – assuming physical security controls are in place.

Limit network access

If the system must remain connected, apply the principle of least privilege by limiting:

which devices can connect to or from it, and
the permissions needed to access or run the system.

This reduces the harm it could cause if compromised.

Use a proxy or apply virtual patching

You can place the system behind a proxy that inspects data before it reaches the system. This may include:

enforcing modern encryption protocols, and
restricting access to sensitive features or resources.

Note: Proxy-based controls are only effective for known vulnerabilities. They often require custom rules for each system – which adds costs and complexity. They also risk giving a false sense of security.

How to measure success

The goals of this control are to ensure that:

all existing system assets – including software and hardware – are recorded,
all new assets are recorded when they’re purchased or developed,
all assets are hardened before use, and maintained regularly with patches and updates,
assets nearing end-of-life or end-of-support have a plan for decommissioning before they become legacy systems,
decommissioned assets are removed from the environment and securely destroyed, and
the entire supply chain is accurately recorded.

Key takeaways

Asset lifecycle management requires different parts of your organisation to work together. Internal development, IT, and procurement teams all play a role in recording assets. Choosing a solution that meets everyone’s needs helps ensure it’s used – and helps prevent shadow IT.
Recording and managing assets makes it easier to confirm whether a vulnerability affects your organisation. If a vendor releases a critical patch, you can act faster by checking which assets are impacted.
It’s not always possible to mitigate the risks of legacy systems in your environment. These should be temporary measures while you plan to move to a newer version or system. Running unsupported components carries a high risk – one that becomes harder to manage over time. At a minimum, your organisation should harden these systems and restrict access until they can be removed or replaced.
Legacy systems often rely on outdated network protocols or hardware. This means they can put modern systems at risk. The longer a legacy system stays in place, the harder and more expensive it may become to replace – especially if the people who understand how it works are no longer available.
Cyber attacks affect every organisation in a supply chain. It’s important to understand your organisation’s supply chain and what risks you could face if a supplier is targeted.
Cyber attacks can impact every organisation within a supply chain. As such, it is important to understand your organisations supply chain and what the risks to your organisation are likely to be, if a supplier in that chain is targeted by an attack.