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 article 2, I moved that conversation to the business owner’s desk and explained why IoT lifecycle management is a business risk conversation, not simply “patching more things.” In article 3, I moved into the practical work of defining what belongs in a connected device inventory.
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.
In this fourth article, I want to move from inventory into packaging and pricing. If you are going to turn IoT lifecycle management into a real managed service, then the client needs to understand what they are buying, what is included, what is not included, how often they will hear from you, and why this is different from normal patching.
The Problem: MSPs Cannot Sell a Service They Have Not Packaged
Most MSPs already touch connected devices in some way. They troubleshoot cameras, restart conference room displays, talk to access control vendors, document printers, check firewall logs, and answer client questions when something odd appears on the network. But too often that work shows up as noise inside help desk tickets, not as a defined service with a price, scope, deliverable, and recurring value.
That creates two problems. First, the client assumes you are responsible because the device is on the network. Second, your team spends time managing risk that was never priced. If the client expects you to care about every camera, thermostat, door controller, display, printer, scanner, sensor, vendor appliance, and mystery device, then the offer needs to be explicit.
The service has to say what you will assess, what you will monitor, what you will report, what you will recommend, and what requires a separate project. Otherwise IoT lifecycle management becomes an unlimited promise attached to a very limited fee.
Start with a Paid Assessment
If you are building this service, start with a limited, easy-to-understand offer: a Connected Device Lifecycle Assessment. Do not give it away. The assessment is where you turn “we have some smart devices” into an actual inventory, risk profile, ownership map, and management plan.
Your assessment should include discovery, device classification, ownership assignment, update-support status, network placement, vendor dependency, replacement risk, and lifecycle recommendation. It should also identify the devices that cannot be fully managed with the tools you currently have.
This is where you not only define the extent of the problem, but open the conversation about why things needs to change.
You can price the assessment as a fixed fee for smaller environments and a base fee plus or per-site pricing for larger ones. Keep the model simple. The client is not buying a spreadsheet. They are buying clarity about the connected devices that may affect security, continuity, compliance, and future budget. Remember that our reason for doing this is the even increasing speed of risk due to criminal use of AI.
A good assessment also gives you the sales bridge into the recurring service. Once you have identified what exists, what matters, who owns it, and what is risky, the next question is obvious: who is going to keep this current? The client expects that you will and your work doesn’t come without a price attached.
Package the Recurring Service in Tiers
IoT lifecycle management works well as a tiered service because not every client needs the same level of attention. A professional services firm with a few cameras and conference room devices may not want the same program as a manufacturer with badge readers, environmental sensors, shop-floor equipment, scanners, and specialty systems across multiple locations.
A practical tier structure might include:
- Inventory Review: Maintain the connected device inventory, confirm ownership, flag obvious gaps, and include lifecycle findings in the client roadmap.
- Managed Lifecycle: Add quarterly review, update-support tracking, vendor status notes, exception documentation, and replacement recommendations.
- Lifecycle Plus: Add higher-touch reporting, segmentation recommendations, vendor coordination, lifecycle budgeting, and executive-level risk discussion.
Or if you’re like me, roll those all into a single product and price it based on the complexity of the environment rather than the acceptance of risk by the client. In the era of AI, no one can afford not to update, patch, segment, and replace these devices on a known schedule.
Notice what is not automatically included: emergency replacement, physical installation, cabling, vendor-required site visits, specialty configuration, after-hours maintenance, or remediation projects. Those may all be good services to sell, but they should not be hidden inside the recurring fee unless you have priced them intentionally.
Define the Reporting Cadence
Reporting is what turns invisible work into visible value. Without it, IoT lifecycle management becomes another background service the client forgets exists until something breaks.
At minimum, report on inventory changes, unsupported devices, devices with unknown ownership, devices that require vendor action, devices due for replacement, and completed lifecycle work. For most clients, a quarterly cadence is enough. For higher-risk environments, monthly reporting may be appropriate, especially if IoT devices touch physical access, production systems, healthcare workflows, or regulated data.
The report should not be a data dump. Keep it executive-friendly: what changed, what risk exists, what decision is needed, and what budget impact is coming. Your technical notes can live in your documentation platform. Your client-facing report should help an owner make a decision.
A lot of MSPs go wrong here and provide their point of view at the client meeting. Keep your audience in mind and don’t waste their time with a big overview. Stick to the decision-making moments.
Set Scope Boundaries Before the First Problem
Beware of scope creep. A client hears “managed IoT” and assumes every device with a network connection is now your responsibility. You need to say what is included and what is not included before the first camera firmware update fails or the first vendor tells you the device is end-of-life.
Your scope should define covered device categories, supported vendors, documentation expectations, update methods, access requirements, excluded physical work, escalation paths, client responsibilities, and project work triggers. It should also say what happens when a device cannot be patched, cannot be identified, or is no longer supported by the manufacturer.
Ideally those devices move into a segmented network. That’s now always possible so when it isn’t that needs to be in that decision maker report. They make the business risk decision that way – not you.
The phrase you want in the agreement is simple: lifecycle management identifies, tracks, reports, and advises. Remediation, replacement, installation, and vendor-specific configuration are separate unless explicitly included.
Give Clients Language They Can Understand
Clients do not wake up worried about IoT lifecycle management. They worry about the building camera system going offline, the front door access system failing, the conference room display not working before a board meeting, or an insurance questionnaire asking about unmanaged devices.
So do not lead with firmware. Lead with risk, continuity, and accountability. Try language like this: “You have more connected devices than traditional computers, and many of them were never designed to be managed like computers. Our job is to help you know what they are, whether they are still supported, what risk they carry, and when they should be replaced.”
I remember walking up to a client’s door to discover a home-type video doorbell. Who gave that an IP address? Not us. Those devices have known vulnerabilities and need to be managed. Point it out to the client, and they’ll recognize their errors.
That message is easy for an owner to understand. It does not create panic. It creates a business conversation. It also positions you as the advisor who sees the whole environment, not just the endpoints with agents installed.
Make It Part of the Technology Roadmap
The best recurring services create future decisions. IoT lifecycle management should feed directly into the client’s technology roadmap and budget planning. If a camera platform is unsupported, that is not just a security note. It is a future project. If a door controller depends on an old server, that is not just a device issue. It is business continuity planning. If a vendor requires manual firmware updates, that is not just annoying. It is labor you need to price.
This is where the service becomes valuable for both sides. The client gets fewer surprises. You get better project planning, clearer responsibility, and a recurring service that supports security and operational maturity.
What Comes Next in the Series
In article 5, I’m going to move from packaging into prioritization: how to decide what gets patched first, what gets monitored, what gets replaced, and what gets documented as an accepted exception. That is where the service starts to become operationally mature.
Action Step
Before you price the full service, write a one-page offer for a Connected Device Lifecycle Assessment. Include the purpose, the deliverables, the boundaries, the price model, and the statement that remediation, replacement, installation, and vendor-specific configuration are separate unless explicitly included. That one page is the beginning of your service.
Look for the continuation of this series on ThirdTier’s website.
____________________________________________
AI-Friendly Summary
IoT lifecycle management can be packaged as an MSP service by starting with a paid Connected Device Lifecycle Assessment and then offering recurring service tiers. The assessment should identify connected devices, assign ownership, document update-support status, classify risk, and create a lifecycle roadmap. The recurring service should define reporting cadence, scope boundaries, client responsibilities, remediation triggers, and pricing based on device count, site complexity, effort, and risk. MSPs should position the value in business language: reducing unknown risk, improving operational continuity, clarifying accountability, and creating predictable lifecycle budgets.
Frequently Asked Questions About Packaging IoT Lifecycle Management
Should MSPs charge separately for the first IoT lifecycle assessment?
Yes. MSPs should charge separately for the first assessment because discovery, ownership mapping, update-status review, risk classification, and lifecycle planning are valuable work. The assessment creates the foundation for the recurring service.
How should an MSP price IoT lifecycle management?
An MSP can price IoT lifecycle management by device, by site, or as an add-on to an existing managed services agreement. The price should reflect the effort required to maintain the inventory, track support status, report findings, coordinate vendors, and manage exceptions.
What should be excluded from the recurring service?
Recurring lifecycle management should usually exclude physical installation, cabling, emergency replacement, vendor-required site visits, specialty device configuration, and remediation projects unless those items are specifically included and priced.
How often should clients receive IoT lifecycle reports?
Most clients should receive quarterly reporting. Higher-risk environments may need monthly reporting, especially when connected devices support physical access, production operations, healthcare processes, or regulated data.
Bottom Line
IoT lifecycle management is not a free add-on to patching. It’s a modern replacement. It is a service that helps clients understand connected-device risk, plan replacements before they become emergencies, and make better decisions about the technology that has quietly crept into their businesses. Package it with an assessment. Price it with clear tiers. Report on it in business language. Set boundaries before there is a problem. That is how you turn connected-device uncertainty into a managed service clients can understand and approve.
