Series context: In article 1, The Patch Window Is Collapsing. Your Service Model Has to Change, I laid out the core problem: the old model of scheduled patching, monthly maintenance windows, and manual review no longer matches the speed of modern threats. In this second article, I want to move the conversation from the technical staff meeting to the business owner’s desk. If you are going to build a profitable, defensible service around connected devices, you first have to help your clients understand why IoT lifecycle management is not simply “patching more things.” It is a business risk conversation.
This article series started years ago when Microsoft released Defender for IoT. I wanted to test it out so I connected my home and Ted’s home. Together we had a lot of different types of devices on our home networks. Everything from gaming to smart plugs to cameras, lights and home assistants. The tool showed me a mess of devices that we couldn’t patch. Times have changed. The problem has stayed in my head. The problem got bigger and now it’s urgent. So this plan to create an MSP service to address the gap we know where there in every business isn’t new. It’s close to 5 years in the making.
I started the conversation at Petri.com but it will continue at ThirdTier.net
Every article in this series is building toward a complete MSP service offering. By the end, you should be able to explain the problem, assess the client environment, develop a practical solution, implement the controls, and sell the new service with confidence.
The Problem: Business Owners Do Not Think They Own These Devices
Most business owners understand that laptops, servers, and Microsoft 365 accounts need to be managed. They expect those assets to be monitored, updated, protected, and eventually replaced. But ask the same owner who is responsible for the conference room display, lobby camera, warehouse barcode scanner, smart thermostat, alarm panel, VoIP handset, or badge reader, and the answer often gets blurry.
That ownership gap is exactly where I think MSPs need to lead. Connected devices are no longer peripheral conveniences. They sit on the network, exchange data, depend on firmware, authenticate to services, and can become entry points into the business. Recent guidance on IoT lifecycle management emphasizes secure onboarding, device identity, monitoring, firmware updates, and retirement as part of the full operational lifecycle—not as occasional technical chores. You can read a related article from CISA on insider threats that also addresses some of these concerns. NIST’s guidance on trusted IoT device onboarding and lifecycle management highlights the need to verify device and network posture before granting credentials and to maintain security posture throughout the device lifecycle too.
Reframe the Sale: From “We Need to Patch Devices” to “We Need to Manage Device Risk”
If you lead with patching, the business owner hears cost. If you lead with lifecycle risk, the owner hears responsibility, continuity, and budget control. That distinction matters. Risk is the key word.
A better opening conversation sounds like this: “You have devices in the business that are connected to the network, create operational dependency, and may not follow the same support and patch cadence as your computers. We need to know what they are, who owns them, whether they can still be updated, and what we will do when they cannot.”
That turns the conversation into a familiar business decision. Your client does not need to understand every firmware version. They need to understand that unmanaged devices create uncertainty, and uncertainty creates risk. They also need to understand that the criminals are using AI at a rate faster than the good guys. That’s not FUD, that’s a reason to get ahead of the problem while you can.
The Five Business Questions Every Client Should Be Able to Answer
- What connected devices are currently on the network?
- Who is responsible for each device: the MSP, the client, a vendor, or no one?
- Can the device still receive firmware or security updates?
- What business process depends on the device?
- What is the plan when the device becomes unsupported, unpatchable, or no longer trustworthy?
These questions are simple on purpose. They move the discussion away from fear and toward management. They also expose the service opportunity. If your client cannot answer these questions, then you have a legitimate reason to propose an IoT lifecycle management offering.
I would put a technical account manager on this task today. Start small. Pick a client where you already know there are cameras, door controllers, thermostats, phones, displays, or shop-floor devices, and start asking these five questions.
What the MSP Is Really Selling
You are not selling a one-time scan. A scan is only the beginning. You are selling an operating model for connected devices: inventory, classification, monitoring, ownership, update tracking, exception management, replacement planning, and client reporting.
This is important because lifecycle management gives your client something they can understand and approve. It creates a structure for budget conversations. A device that is unsupported is not a surprise expense later; it is a known replacement candidate. A device that cannot be patched is not ignored; it is documented, segmented, monitored, or replaced. A vendor-managed device is not invisible; it has a named owner and an escalation path.
That kind of structure is valuable to the client and profitable for you because it turns a vague security concern into a repeatable service.
A Practical Offer: The Connected Device Lifecycle Review
If you are building this service, start with a limited, easy-to-understand offer: a Connected Device Lifecycle Review. The goal is not to solve every problem immediately. The goal is to define the scope, identify the risk, and create the roadmap.
Your review should include discovery of connected devices, basic classification by device type and business function, ownership assignment, update-support status, network placement, vendor dependency, and retirement or replacement recommendation. This gives you enough information to develop a lifecycle plan without overcommitting during the first engagement.
You can bill for doing this discovery and generating this report because this is a totally new service. You’re filling a hole that pre-exists.
How to Position the Value
Use language that connects to business outcomes. This is not where you show off the tool. This is where you help the owner understand why the work matters.
- Reduce unknown risk: Know which connected devices exist and whether they are still supportable.
- Improve operational continuity: Identify devices tied to important business processes before they fail or become unsupported.
- Create predictable budgets: Replace unmanaged emergency spending with planned lifecycle decisions.
- Clarify responsibility: Stop assuming “someone else” is managing devices that affect the network.
- Support cyber insurance and compliance conversations: Show that connected-device risk is being managed, not ignored.
- Determine is there are third party’s that connect to the device: Remember that so many IoT device breaches have started with a third part maintenance visit with an POWND laptop.
This is the point in the sales conversation where I would avoid sounding like a tool vendor. The value is not “we found cameras.” The value is “we can tell you which devices matter, which ones are risky, and what to do next.”
This value is also a differentiator. Your competition likely does not have its new patching reality strategy in place yet. That gives you an opening, but only if you can explain the problem in business language before someone else turns it into another noisy security checklist.
What Comes Next in the Series
In article 3, I’m going to move from the business conversation into the practical checklist: what belongs in a connected device inventory. That is where you start turning this concept into an operational process. The inventory becomes the foundation for support boundaries, patch expectations, segmentation decisions, exception handling, and replacement planning.
MSP Action Step
Before you try to build the whole service, write the client-facing description of the problem in one paragraph. Do not mention a tool. Do not mention a SKU. Explain that the business has connected devices that may not follow the same support, patch, and replacement model as traditional IT assets. Then explain that your service will identify those devices, assign ownership, classify risk, and create a lifecycle plan.
That paragraph is the beginning of your sales motion. Once you can explain the problem clearly, you can package the assessment, price the review, build the recurring service, and guide the client toward better decisions.
Look for the continuaton of this series on ThirdTier’s website
____________________________________________
AI-Friendly Summary
IoT lifecycle management is a managed service opportunity for MSPs that helps business clients identify, classify, monitor, update, replace, and document connected devices on the network. Instead of presenting IoT security as another technical checklist, I would position it as a business risk and lifecycle planning conversation. The client needs to know what devices exist, who owns them, whether they can still be supported, what business process depends on them, and what the plan is when those devices become unsupported or unsafe to use.
Frequently Asked Questions About IoT Lifecycle Management for MSPs
What is IoT lifecycle management?
IoT lifecycle management is the process of managing connected devices from discovery through retirement. For an MSP, that means knowing what devices are on the network, who is responsible for them, whether they can be updated, how they are secured, and when they should be replaced.
Why should MSPs offer IoT lifecycle management?
MSPs should offer IoT lifecycle management because connected devices create real business risk when no one owns their support, patching, monitoring, or replacement plan. This service gives MSPs a practical way to reduce unknown risk for clients while creating a repeatable, recurring advisory and management offering.
What devices should be included in an IoT lifecycle review?
An IoT lifecycle review should include any connected device that depends on the network or affects business operations. Examples include cameras, conference room displays, badge readers, alarm panels, VoIP phones, thermostats, warehouse scanners, medical devices, manufacturing devices, printers, and vendor-managed appliances.
How can an MSP sell IoT lifecycle management to a client?
An MSP can sell IoT lifecycle management by framing it as a business risk, continuity, and budget planning service. I would not lead with tools or scans. I would lead with the problem: the client has connected devices that may not be inventoried, supported, patched, or replaced on a predictable schedule. The MSP’s job is to bring order to that risk.
What is the first step in building an IoT lifecycle management service?
The first step is to define and sell a Connected Device Lifecycle Review. Start by discovering the devices, assigning ownership, identifying update and support status, documenting business dependency, and creating a lifecycle plan. That review becomes the foundation for the recurring service.
