A commodity capability is a function that many vendors already deliver in a standard, repeatable way. It is usually not a source of competitive advantage, so buying it often makes more sense than building it. Examples include common infrastructure, compliance-heavy applications, and routine access or operations workflows that do not require unique logic.
What Makes a Capability “Commodity”
Commodity capability is the part of a product or service that buyers can now expect almost anywhere. It is standardized, repeatable, and usually interchangeable enough that the market no longer treats it as a differentiator.
That does not mean the capability is unimportant. It may still be essential to operations, security, or compliance. The point is that the core function is widely available, so the real decision becomes whether the organisation should own the work itself or consume it from a provider that already delivers it well.
Where Commodity Capability Shows Up
Commodity capabilities often appear in areas where vendors have converged on common patterns, such as routine infrastructure, baseline access workflows, and compliance-heavy application functions. They also show up in operations where the logic is predictable and the business value comes from reliability more than novelty.
These capabilities are often embedded inside broader platforms rather than sold as stand-alone innovations. A buyer may still need to evaluate integration, resilience, support, and control, but the underlying function is usually no longer unique enough to justify custom build effort.
For that reason, commodity capability is less about whether the function matters and more about whether it still requires proprietary design. If many providers can deliver the same outcome with similar quality, then the capability is behaving like a commodity.
Why Build Versus Buy Changes Here
The concept matters because it helps separate strategic differentiation from necessary plumbing. When a capability is commodity-like, building it in-house often adds cost, maintenance burden, and delivery delay without creating meaningful competitive advantage.
Buying a commodity capability can also shift effort toward higher-value work, such as product differentiation, process improvement, or control assurance. In security-heavy environments, that may mean focusing internal engineering on the truly unique parts of the environment while relying on mature market offerings for standard functions.
The trade-off is that “commodity” should not be mistaken for “low consequence.” A standard capability can still carry serious risk if it is poorly configured, weakly governed, or overexposed. The fact that a function is common only means the function itself is not unique; it does not remove the need for careful control.
How Practitioners Should Interpret the Term
Commodity capability is best used as an architectural and sourcing lens, not a quality label. It helps practitioners ask whether they are spending effort on something that should be treated as a baseline utility rather than a bespoke engineering problem.
Common misunderstanding: teams sometimes assume commodity means “unimportant” or “safe to ignore.” In practice, commodity functions are often the exact areas where control discipline matters most, because their standardisation makes them easy to adopt broadly and easy to misuse at scale.
Governance implication: organisations should distinguish between capabilities that define their competitive edge and capabilities that should be governed as shared services, purchased controls, or managed operational functions. That distinction shapes sourcing, ownership, and where internal expertise is best invested.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Commodity access workflows often map to standard account governance. |
| Recommendation — Standardise account lifecycle controls for routine access workflows you do not need to custom-build. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Commodity operational capabilities still need clear access governance and policy control. |
| A.8.9 — Configuration management | Commodity services still depend on repeatable configuration rather than bespoke logic. | |
| Recommendation — Apply access control policy to standardise how shared capabilities are authorised and used. Use configuration management to keep standard capabilities consistent across environments. | ||
Related resources from NHI Mgmt Group
- What breaks when a credentials vault is treated as a commodity?
- How can teams tell whether a new platform capability is changing their risk posture?
- How can MSPs move from commodity support to higher-margin identity services?
- How should organisations reduce SaaS spend without losing business capability?
