The Software Management Maturity Model: How Software Management Practices Reveal Organizational Maturity

Regardless of the topic, honest recognition doesn’t typically come automatically. In software update management, the reasons that an objective analysis is often missed are circumstantial rather than technical.

New product pressures

Software update management commonly arrives late in the product development cycle, during a rushed pre-launch scramble; a small engineering team assembles a solution from open-source components to avoid delaying the imminent product launch. Under product launch pressure, it’s an understandable response. But a decision influenced by pressure is not the same as a decision made through deliberate, strategic analysis.

Treating software management and update delivery as a last-minute technical problem rather than a foundational part of the product tends to resurface as the whole device lifecycle has not been properly thought through. It shows up first in the launch schedule, threatening deadlines and creating issues with user onboarding and device rollout. Later, with products dispersed across the market, poorly planned lifecycle management can lead to severe consequences, like fleet-wide outages, security breaches, and bricked devices.

The data bears this out. In the 2026 State of Industrial IoT Device Lifecycle Management report, only 18.1% of original equipment manufacturers (OEMs) report always meeting their release deadlines regardless of product age (newly launched or well-established). Software, spanning deployment, bugs, and patches, is the single most frequently cited cause of delay, named by 49.1% of respondents .¹ These are the operational costs of poor software management: missed deadlines, unstable updates, fleet outages, compliance gaps, resources diverted to maintenance, subpar user experiences, and reputational damage. The costs appear later and compound through the lifecycle, affecting the operations of the entire organization.

Incomplete contextual analysis

Use cases and specific conditions genuinely influence where an organization lands on software update management. The difficulty is weighing all conditions with a future-focused mindset. A company with a fleet of 500 devices today, for instance, might reasonably build a simple in-house software delivery system to fit that scale; but the decision to build a solution and what it requires looks completely different if their roadmap calls for 50,000 devices in the future. The mechanism at 500 is unlikely to hold as the fleet scales.

Similarly, a company entering a market with light regulatory requirements today may find its compliance obligations expand considerably as its product line grows, or as it moves into adjacent markets. Weighing conditions as they exist right now, without accounting for where the business and its regulatory exposure are headed, results in a decision that fits today and fails tomorrow.

Once an organization understands where software update management actually sits, the specific answer for its own use case tends to follow directly. What an organization’s approach to software management reveals is less about the answer it reaches, and more about whether it was in a position to ask the question clearly in the first place.

Initial stage bias

Where an organization starts on this journey is equally impactful. New entrants, building smart products from scratch, have an opportunity incumbents don’t: a blank canvas. Nothing is built yet, so there’s a real chance to determine strategic intention and operational capability from day one, before any infrastructure exists to defend or unwind. A clean slate makes it easier to become a mature organization where intent and practice align, but doesn’t make it automatic.

Incumbents usually start from a different position. Many built their first update mechanism years or decades ago, before purpose-built infrastructure was well understood, and that system is often still in place, doing what it was built to do.

Neither starting point determines the outcome. A new entrant with a clean slate can still end up building a solution unnecessarily, pulled by budget pressure, unfamiliarity with what already exists, or capability-over-fit reasoning. An incumbent with years of sunk cost in a self-built system can still deliberately revisit that decision, and many do. The starting point shapes how hard the question is to ask. It doesn’t answer the question for the organization, and it isn’t an excuse not to ask it.

Maturity is strategic clarity. Ultimately, it is knowing which parts of the product and supporting infrastructure differentiate the business in the market, and which do not.

Maturity, in this context, isn't a measure of how much an organization builds in-house. A team that builds its own software update management infrastructure isn't automatically less mature than one that buys a vendor solution, and the reverse holds just as true. Maturity is also not a measure of scale or sophistication; an organization can run the most advanced in-house update system in its industry and still be immature if the right call and investment were to outsource. What makes an organization mature isn’t the choice made, but the justification behind it.

Equally important to note: commonplace or commodity, here, doesn't mean unimportant. A failed software update can still brick a device, breach a Service Level Agreement (SLA), or trigger a compliance failure — real business risks by any measure. Commodity means a capability the business needs, but not a core competence. Commodities are not distinguishing features or capabilities. The outcome matters enormously, but the specific mechanism used to achieve it is not what customers are buying or what competitors are losing to. Email delivery is a commodity in this sense; a failed email system is a real capability failure, but almost no company treats building its own mail server as a core competence worth investing in.

Maturity as strategic clarity plays out along two axes, best described as practice and intention.

• Practice is where an organization actually stands today, where its choices, deliberate or circumstantial, have left it. Practice is a measure of execution and the actual performance of the infrastructure in place. Practice, on its own, doesn’t show why the organization is where it is. It only says how well it’s doing what it’s doing.
  
  
• Intention is the less visible element: why the organization is where it is. Today’s stage, regardless of what that is, does not indicate whether that position was chosen or surreptitious. For some organizations, today’s position is the product of learning as you go, moving from manual, device-by-device fixes toward a more automated and purpose-built process only as each limitation becomes too costly to ignore. For others, it's the result of planning ahead and choosing the proper approach for the organization from the start, skipping that progression entirely.

When it comes to software update management, the question underlying intention is whether the update mechanism is a source of competitive differentiation or merely supporting infrastructure. Intention is a direct reflection of maturity. Organizations tend to fall into one of three positions here.

1. Some have asked that question and answered it according to the actual novelty of the problem, not the felt novelty.
2. Others haven’t asked the question at all; their current practice is simply where momentum left it.
3. And in between sits a third, easy-to-miss group: organizations that did ask the question, but let other factors or considerations skew the answer. Asking the question is necessary, but it isn't sufficient on its own. It has to be answered honestly.

None of these three positions (maturity) says anything about how well the organization is actually executing (practice). An organization that never asked the question can still run a highly capable system, and one that asked and answered honestly can still be struggling operationally. Intention reflects maturity and explains why an organization is where it is; practice describes how well it’s doing at a given point in time. They move independently of one another, and conflating the two is where many organizations reach a roadblock.

Consider two organizations that both built their software management infrastructure in-house.

For one, the update infrastructure is the product; a company whose update mechanism is inseparable from its value proposition. Building in-house is an intentional choice, given that the necessary resources and expertise are available, and most importantly, because the software update system is a significant differentiator. The system runs well, deployments are reliable, the fleet is visible, and failures are rare and recoverable. Intention is well-founded, and practice is aligned; this is a strategically mature organization.

For the other organization, the same decision was made because a small engineering team believed they could build the update mechanism before launch. No one thought to ask whether the update mechanism set the product apart in the market. The system holds up just as well: updates roll out successfully, edge cases are handled, and the fleet stays healthy and accounted for. The system does its job, but it isn’t why customers choose the product, and it never was. Practice looks identical, but intention is absent, reflecting an immature organization.

What differs is whether each organization actually knows why it built what it built, and that difference doesn’t show up in the audit of the system itself. It shows up in the opportunity cost each organization absorbs; the next time a real alternative appears, one organization can explain why staying the course still makes sense, while the other has no answer beyond the fact that the system already exists.

Conflating the two elements of maturity is a common example of predictable bias. Teams tend to anchor on practice rather than intention. The question that gets asked is, "Can we build this?" not "Should we be the ones building this?" Once an in-house system exists and is working, revisiting the decision means weighing the years and resources already invested (sunk costs) against a hypothetical alternative. It’s natural to trust a system built by people you know and can talk to over one built by an outside vendor, regardless of how the two actually compare. A related instinct operates in the background, too: the team that built the system naturally wants to defend it. These instincts are natural, and they surface in real-world examples.

What these instincts do, though, is make the question of intention easy to skip. The practice question, “Are we capable of running this system?” tends to get answered instead. Sometimes it's answered well, because the team is genuinely capable. Sometimes it isn’t, and the gaps only surface later, in fragmented, undocumented systems. But operating a system well and having deliberately chosen to build it are two different achievements. Simply, intentionality must be put to a real test.

A mature organization can concisely explain why software update management is or is not core to its competitiveness, and its practice reflects that answer. An immature organization has never asked the question, and its practice, whatever form it takes, is simply where momentum left it.

Software update management today is a complex problem that compounds across multiple dimensions simultaneously. Device diversity is the first layer. Fleets rarely run a single hardware platform with one operating system. A single product line often contains multiple hardware revisions and software versions in the field at once, and more commonly, a single product contains various, interdependent components. A typical fleet spans multiple hardware revisions, several OS versions, and, increasingly, on-device AI models that require their own update path, each combination requiring its own tested, validated software update delivery.

Fleet scale adds a second layer. Deployments span thousands to millions of devices, distributed across geographies with inconsistent connectivity, from reliable broadband to intermittent cellular to fully offline, air-gapped environments. A single failed rollout doesn’t stay contained to one device; at fleet scale, the same issue can spread to every unit sharing that version before anyone notices. What was manageable at a small scale becomes an exponential number of hardware-software combinations to track and validate as the fleet grows.

Regulatory obligation defines a third layer. The European Union’s Cyber Resilience Act (CRA), Radio Equipment Directive (RED), and Network and Information Security Directive 2 (NIS2) all require audit trails, security-by-design, and demonstrable integrity of software updates. The United States imposes its own requirements across industries, including the FDA’s Cybersecurity Section 524B for medical devices, the NIST Cybersecurity Framework as a widely adopted baseline, ISA/IEC 62443 for industrial automation, and ISO/SAE 21434 for automotive, just to name a few. A single company selling into multiple markets or industries across the globe can find its fleet accountable to several of these regulations simultaneously, each with its own documentation, auditing, and compliance requirements.

Security is the dimension underneath all three. Regulations are growing in prominence because security failures are more costly and possible in the age of smart devices. An unpatched vulnerability in the field is an open door to the exact adversaries these regulations aim to defend against, and a breach that reaches production devices is measured in recalls, liability, and lost trust, not just engineering time. Achieving and maintaining compliance takes real operational competence, sustained over the lifecycle of every device in the fleet, not just at launch.

This complexity isn’t going away, and it isn’t likely to simplify. Fleets will keep growing, products will continue to advance, and hardware-software combinations will keep multiplying as AI-driven features and edge computing become standard. Additionally, regulatory bodies show every sign of expanding coverage, as more categories of connected products come under scrutiny.

Getting software update management right today is table stakes. Maintaining that standard as all three dimensions continue to compound is an ongoing demand on the organization, not a one-time technical decision to be made at launch and set aside.

Many organizations, whether intentional or not, move through a recognizable progression as their approach to software updates matures. Each stage varies in:

• Deployment: The actual mechanism used to deliver updates
• Scalability: The ability to maintain performance as the fleet grows
• Security: The safeguards built into the update process
• Compliance: The capabilities to satisfy regulatory requirements
• Maintenance: The ongoing effort required to maintain the system

Four stages make up this progression, starting with the most limited approach and ending with the most capable. The ladder reflects the progression as it typically unfolds among connected device OEMs.

Stage 1: Manual update system

At the earliest stage, updates happen by hand. A technician connects over SSH, plugs in a USB drive, or visits a device in the field. In consumer contexts, this stage can also take the form of a service appointment or, in more serious cases, a product recall.

Benefits

Many connected products begin with a manual update system, and for some, it remains a deliberate, defensible choice. An energy management systems provider, for example, originally maintained its fleet through a combination of direct SSH access and AWS Greengrass for application-level deployments.² Manual updates work well where fleets are small, changes are infrequent, or a technician is already on-site for other reasons. The approach carries no infrastructure to build or maintain beyond what already exists.

Done well, with consistent documentation and a defined process, a manual approach can also satisfy regulatory expectations: a scheduled service appointment, similar to a car brought in for maintenance, produces a clear, auditable record just as a remote, purpose-built system would.

Challenges

Where manual update systems tend to struggle is scale. Each update requires direct, individual attention, a technician's time, truck roll, or site visit, so the cost and time required grow in step with the fleet. There are no economies of scale. A process that works comfortably for dozens of devices can become a significant operational burden at hundreds, and impractical at thousands.

Audit trails, while achievable, depend heavily on discipline and consistency: a rushed field fix is less likely to be documented as thoroughly as a scheduled one, and that inconsistency, more than the manual method itself, is usually where compliance risk emerges. Regulations like the EU CRA, the RED, and NIS2 expect demonstrable traceability and timely patching; a well-run manual process can produce both, but an ad hoc one often can't, and proving otherwise after the fact is difficult. The engineering effort involved is also mostly reactive, weighted toward responding to individual issues as they arise rather than building toward scale. Remediating a known vulnerability is often a question of how quickly every device can be physically reached, not whether a fix exists.

Stage 2: Initial custom system

The next stage is a custom system, often built quickly around one product. It's typically assembled from open-source components under launch pressure, with the goal of getting software deployed in time for launch.

Benefits

A custom-built system solves the immediate problem: it gets the product shipped without waiting on procurement, vendor evaluation, or integration timelines that don't fit a launch deadline. It's tailored precisely to one product, with no unused capabilities or external dependencies. For a team that already has the open-source components and in-house familiarity to assemble it, the upfront cost can look genuinely low. For a single, well-understood product with a narrow scope, this can be a reasonable way to get to market.

Challenges

Where this stage tends to run into trouble is durability and scope. An initial version built under launch pressure is typically fragile and tends to remain so because system management wasn't the discipline that built it. Documentation is often thin or absent, and visibility into a software bill of materials (SBOM) or known vulnerabilities (CVEs) is limited or missing entirely.

This is also where fragmentation tends to set in. It's not uncommon for a single incumbent organization to accumulate two or more of these systems over time, each built to solve an immediate problem for a specific product line, with no coordination among them. One organization, for instance, disclosed seven separate software update systems in use across its product lines.³

The risks for this stage are also not hypothetical. In one documented case, a company failed to account for how long products would sit on shelves before activation. New features and rushed deployments broke backward compatibility, and when customers activated newly purchased products from inventory, the products couldn't communicate with the infrastructure meant to update them. A meaningful share of the company's fielded devices became unusable, and the company didn't survive the fallout.

Scale is generally limited to whatever the original engineers anticipated at the time, which is rarely enough as the product line grows. Compliance posture tends to be weak, since security-by-design wasn't necessarily a guiding principle under launch pressure, and both engineering effort and business risk tend to grow quietly, often invisible until something breaks.

Stage 3: Advanced in-house system

By Stage 3, the organization has built an advanced, genuinely capable system: an automated pipeline, real fleet management, a system that no longer relies on manual, one-off intervention.

Benefits

An organization at this stage has solved most of the problems that plague Stage 1 and Stage 2. Updates deploy without manual intervention, the fleet is visible and trackable, and the team has built genuine operational muscle around versioning, rollout logic, and failure handling. For organizations with the resources and sustained investment to achieve this level, the system can perform on par with a commercial or best-of-breed solution, and the team retains full control over its roadmap and integration with the rest of the product's infrastructure.

Challenges

It's tempting to treat this stage as the finish line, but updating a single product is easy; updating a large-scale fleet or a multi-component product is not. Managing versioning, device state, rollout logic, and failure handling typically represents 80 to 90% of what a real software update management solution requires, and it's exactly where gaps emerge in homegrown systems.

A system of this caliber also typically entails a permanent maintenance obligation: security patches, new device variants, evolving compliance requirements, and containerization or delta-update capabilities that weren't part of the original design. Scale is real but strained; compliance posture is better but still requires continuous, manual upkeep as regulations shift; and the business risk is slow erosion: the system works, but the organization is quietly paying for it in resources that could go elsewhere.

Stage 4: Best-of-breed infrastructure

At the top of the ladder, the organization gets its engineering time and attention back, in full, without giving up the confidence that updates will land safely and withstand regulatory scrutiny. That confidence comes from a full-lifecycle solution: compliance-ready by design. This is the stage most homegrown systems aim for, and it's also the stage where commercial solutions typically enter the picture: infrastructure that absorbs the internal maintenance obligations and complexity described in Stage 3.

Benefits

Organizations here are free to focus on what differentiates them, because an entire trusted vendor organization is now dedicated to the update mechanism on their behalf. Engineering time that would go toward building and maintaining software management infrastructure goes back to the product itself. Compliance posture is strong by default rather than by ongoing effort; fleet visibility and audit logging are built in; and the operational risks that define the earlier stages, inconsistent audit trails, fragile backends, slow erosion of engineering capacity, are largely resolved.

Challenges

Stage 4 introduces its own trade-offs. Recurring license costs replace internal engineering resources, and dependence on a vendor’s roadmap, pricing, and continuity replaces an internal team the organization directly controls. Yet, many mature organizations mitigate these risks by choosing open standards, open-core solutions, or source-code escrow options.

Reaching this stage demonstrates operational practice: the organization has solved the how of software updates. It doesn't, by itself, demonstrate strategic maturity, which is a separate question about why. An organization can reach Stage 4 by building an excellent in-house system for the wrong reasons, or by buying a best-of-breed solution without ever asking whether software updates were core to its business in the first place. Operational practice and strategic clarity are not the same achievement, and mistaking one for the other is where the ladder's usefulness runs out. Whether an organization actually needed to arrive here, and whether it needed to build the path itself, are questions the stage cannot answer on its own.

Correctly classifying software updates within the business is narrower than asking "Is software management important?" Nearly every organization would answer yes, and they'd be right; a failed software update is a real business problem.

The operative question is different: do customers choose us over competitors because of how we deliver updates? For almost every organization, the honest answer is no. A customer buying an industrial sensor, a medical device, or a fleet management platform is buying what the product does. Whether software updates arrive through a self-built pipeline or a commercial, best-of-breed platform is invisible and inconsequential to them, just as a company evaluating an enterprise resource planning (ERP) vendor doesn't ask whether that vendor runs Salesforce or Oracle for its own sales team.

That, however, doesn't make robustness optional. A compliance-ready system, future-proofed to stay predictable, accountable, and audit-ready over the full lifecycle, is what makes the system, and by extension the product, trustworthy at scale. An organization that gets this right experiences fewer bricked devices, less unplanned downtime, and a materially stronger security and compliance posture.

But an excellent update system existing and an organization building that excellent system itself are two different claims, and only the first one is required. The product needs robust update management. It doesn't follow that the organization needs to be the one that builds it. This is where the conflation usually happens: teams correctly conclude that updates must be excellent, and then, without examining the leap, treat "must be excellent" as though it means "must be built here." Whether the business builds that robustness itself, or buys from a vendor who has already built it to the same standard, is a separate question entirely, one only a small number of companies, those for whom the update mechanism is the product or close enough to it, will reasonably answer by building.

This isn't an all-or-nothing choice. Build and buy aren’t the only two options on the table, and for many organizations, a third path fits better. For organizations with a large, already fielded fleet, replacing a homegrown system outright can be a source of risk itself. For these organizations, augmentation, layering commercial components onto an existing system rather than replacing it wholesale, is a possible alternative. For example, an abstraction layer, audit logging, role-based access control, and real-time inventory for SBOM and CVE tracking can be added incrementally without a full rip-and-replace.

The forward-thinking OEMs treat software management strategy as essential as infrastructure decisions, understanding the “why and how” that each piece plays in robust operations and product offerings.

Answering the requirements of future-proofing with real rigor — quantifying the full cost of each path, weighing the risk of changing against the risk of standing still, and modeling the business value in financial terms — is a strategic decision that can affect OEM success in the long term. Check out The economics of software update systems: Measuring the total cost of ownership for building and buying solutions to learn more about the economics of building versus buying software update infrastructure, including a full methodology and a structured scoring framework.

Resources

1. https://northern.tech/dlm-industry-report-2026

2. https://mender.io/resources/case-studies/octave-energy-case-study

3. https://mender.io/resources/reports-and-guides/custom-built-ota