This article provides a comprehensive analysis of the UK Government’s proposed 2025 Code of Practice for Enterprise Connected Device Security, published by the Department for Science, Innovation and Technology (DSIT). It unpacks the structure, rationale, and policy intent behind the Code, outlines its 11 lifecycle-aware security principles, and evaluates its strengths and limitations. Drawing on lessons from the earlier NCSC Cyber Resilience Testing (CRT) programme, it offers a set of practical, actionable recommendations to improve uptake, scalability, and long-term impact. This is a roadmap for policymakers, manufacturers, and enterprise buyers navigating the emerging landscape of connected device security in organisational settings.

Contents

Introduction

The publication of the UK Department for Science, Innovation and Technology’s (DSIT) proposed Code of Practice for Enterprise Connected Device Security marks a pivotal moment in the evolution of national cyber resilience strategy. It reflects a long overdue recognition that connected devices in organisational environments, from VoIP phones and smart displays to storage systems and industrial controls, represent a rapidly growing, insufficiently governed attack surface.

Having previously contributed to the NCSC’s Cyber Resilience Testing (CRT) initiative, I view this Code not as a wholly new departure, but as a continuation, expansion, and maturing of the UK’s secure-by-design philosophy, albeit one with several key innovations and course corrections.

What follows is both an endorsement and a critical reflection: a policy analysis grounded in experience, and a set of recommendations that, if implemented, would move this Code from advisory to transformational.

The Core Problem: Security Gap in Enterprise IoT

The risk posed by enterprise-connected devices is not theoretical. These devices are often deployed at scale, are insufficiently monitored, and may hold sensitive operational data or access to critical systems. Worse, most organisations lack visibility into their configuration or lifecycle status.

While the PSTI Act (2022) brought enforceable standards to consumer-grade devices, enterprise IoT has remained underregulated, despite posing far greater systemic risk. The DSIT Code aims to plug this regulatory gap by providing 11 practical, lifecycle-aware principles, each underpinned by technical guidelines.

In response to these rising systemic risks, the Department for Science, Innovation and Technology has published a draft Code of Practice for Enterprise Connected Device Security. You can read the full consultation document here: https://www.gov.uk/government/calls-for-evidence/call-for-views-on-enterprise-connected-device-security

What follows is a comprehensive deep dive into that document, its scope, structure, policy objectives, and implications, before we turn to its strengths, gaps, and potential improvements.

Understanding the DSIT Code of Practice for Enterprise Connected Device Security

The DSIT Code of Practice for Enterprise Connected Device Security (2025) is a government-led intervention designed to close a growing and dangerous gap in the UK’s national cyber security posture: the lack of baseline protections for connected devices deployed in enterprise settings.

It is, at its core, a policy tool, not just a technical document, intended to drive secure-by-design principles into the supply chain, product development lifecycle, and procurement decisions of manufacturers, solution providers, and enterprise buyers of Internet-connected devices.

While the Product Security and Telecommunications Infrastructure Act (PSTI) 2022 brought enforceable requirements to consumer IoT devices, the enterprise class of connected systems has remained a regulatory blind spot. These devices, which include printers, VoIP phones, video conferencing units, NAS boxes, and digital signage, are commonly deployed without formal risk assessments, long-term update strategies, or sufficient hardening.

DSIT’s Code is an attempt to codify baseline security expectations, aligned with principles co-developed with the National Cyber Security Centre (NCSC) and informed by prior work including the 2022 Device Security Principles for Manufacturers and feedback from industry, academia, and civil society.

It is deliberately structured to:

• Raise awareness among buyers and vendors about common failure points in enterprise devices.
• Enable market signalling, so buyers can choose more secure equipment.
• Support future regulation, through voluntary adoption now and legislative intervention later.
• Align with international standards (ETSI EN 303 645, ISO/IEC 27402) while addressing the unique threat landscape of organisational networks.

Structure of the Code

The Code comprises 11 security principles, each backed by a series of implementation guidelines. These principles span the full lifecycle of a connected device, from design and onboarding to updates, monitoring, access control, recovery, and end-of-life.

The document also includes:

• A policy rationale highlighting the systemic risks of unsecured enterprise devices.
• Definitions and scope, establishing what constitutes an enterprise device.
• A discussion of three potential policy interventions:
  • A voluntary industry pledge
  • Development of a new global standard
  • Expansion of legislation (either through the PSTI Act or new primary legislation)
• A call for views, with specific feedback mechanisms via online survey and consultation workshops.

The framing language of the principles uses a clear modal hierarchy:

• Shall = mandatory for conformity
• Should = recommended, but context-dependent
• Can = optional, best-effort features

This provides a scaffold for both minimum viable compliance and security maturity growth.

Why These 11 Principles?

The 11 principles collectively address the attack vectors, persistence mechanisms, and operational weaknesses most commonly exploited in connected device breaches.

They also reflect:

• The lessons learned from major global incidents such as Mirai (2016), where enterprise-grade IP cameras and routers were co-opted into DDoS botnets.
• Ongoing threat research highlighting widespread use of default credentials, outdated firmware, open interfaces, and lack of observability in enterprise deployments.
• The UK’s commitment to zero trust architectures, supply chain integrity, and resilience-by-default.

In short, they are technically rigorous but designed for cross-functional application: they can be read and implemented by engineers, product managers, CISOs, procurement officers, and compliance leads alike.

Bullet Summary: What’s in the DSIT Code?

• Purpose: Establish a voluntary (but policy-aligned) baseline for the security of enterprise-connected devices.
• Scope: Applies to devices used in organisations that store/process enterprise data, e.g. printers, NAS, VoIP systems, conference systems.
• Why Now?: Growth in adoption, poor current baseline, increased threat activity, and proven vulnerabilities (default passwords, DDoS leverage, outdated software).
• Structure:
  • 11 security principles with detailed sub-guidelines.
  • 3 intervention models: voluntary pledge, international standard, legislation.
  • Public consultation and policy feedback mechanisms.
• Principles cover:
  1. Secure updates
  2. Authentication
  3. Data protection
  4. Device integrity
  5. Health visibility
  6. Trusted software execution
  7. Least privilege
  8. Interface constraints
  9. Device management
  10. Logging and alerting
  11. Recovery and reset
• Language framing: Shall / Should / Can hierarchy for implementation flexibility.
• Policy aim: Prepare industry for future legislative compliance while enabling near-term improvements through guidance and market incentives.
• Alignment with existing work: Builds on NCSC guidance, consumer IoT frameworks, ETSI/ISO standards, and CRT programme lessons.

What the DSIT Code Gets Right

The proposed Code builds intelligently upon the CRT initiative. Where CRT emphasised outcome-based resilience testing for consumers, DSIT now pivots to design-time intervention, supply chain signalling, and long-term lifecycle governance. Key strengths include:

• A lifecycle view: from manufacture and onboarding to update, monitoring, and decommissioning.
• Enterprise-specific controls: such as remote attestation, centralised fleet management, and granular role-based permissions.
• Flexible language: using “shall”, “should”, and “can” to denote enforcement strength.
• Alignment with international standards: notably ETSI and ISO frameworks.

In short, it presents a technically literate, commercially aware, and internationally relevant framework for connected device security in business and public sector contexts.

But It Can, and Must, Go Further

1. Introduce Risk-Based Tiering

Why it matters:
Not all enterprise devices are equal. The risk posed by a networked room-booking display is not comparable to that of an internet-facing medical telemetry unit. Yet the Code treats all devices as functionally similar.

What to do:
Classify devices by risk level, low, medium, high, and tailor compliance requirements accordingly. This aligns with established safety models in aviation, healthcare, and critical infrastructure, where proportionality is a core regulatory principle.

2. Link Compliance to Procurement and Insurance

Why it matters:
CRT’s voluntary nature proved ineffective in shifting manufacturer behaviour. There was insufficient market pull from buyers and no consequences for non-participation.

What to do:

• Embed code adherence in public procurement frameworks.
• Offer cyber insurance incentives for organisations that deploy Code-compliant devices.
• Make conformity a required element in supply chain assurance processes.

This transforms the Code from a “nice to have” to a “must have” for vendors seeking market access.

3. Establish a Lightweight Assurance Mechanism

Why it matters:
Voluntary codes without verifiable compliance risk becoming shelfware. But heavy certification schemes deter SMEs.

What to do:
Create a tiered assurance model:

• Self-attestation with published transparency reports
• Optional third-party validation
• Public registry of conformant products

This balances cost, transparency, and accountability.

4. Clarify Scope and Definitions

Why it matters:
The current definition of “enterprise connected device” is too open-ended. Without scoping clarity, implementation will be patchy and legally ambiguous.

What to do:
Publish an authoritative scoping document:

• Explicit in-scope / out-of-scope device types
• Clarify overlaps with the PSTI Act and industrial IoT standards
• Provide examples across use cases (e.g., healthcare, manufacturing, education)

This reduces compliance friction and enhances legal clarity.

5. Add Secure Decommissioning and Disposal Guidance

Why it matters:
CRT ignored end-of-life security, and DSIT’s Code still lacks a principle dedicated to post-operational sanitisation. This is a critical omission.

What to do:
Add a 12th principle covering:

• Secure factory reset
• Cryptographic erasure
• Chain-of-custody during disposal
• Linkages to enterprise data retention/deletion policies

Devices eventually become waste. Let’s not make them liabilities.

6. Provide Companion Materials for SME Manufacturers and Buyers

Why it matters:
While the Code is technically robust, it assumes significant cyber maturity. Many SME manufacturers and enterprise buyers lack in-house capability to interpret it.

What to do:

• Publish simplified buyer checklists, implementation templates, and quick-start guides.
• Segment content by device class and organisational size.
• Leverage the success of CRT’s consumer-facing materials for a business audience.

This ensures adoption beyond the cybersecurity elite.

The Legislative Question: Voluntary, Standard, or Statute?

The DSIT proposal outlines three intervention models: a voluntary pledge, an international standard, and potential legislation. All have merit, but none alone is sufficient.

A staged path may be best:

• Phase 1: Voluntary uptake supported by public procurement mandates
• Phase 2: Formalise as an international standard through ETSI or ISO
• Phase 3: Legislate core principles via an updated PSTI Act or standalone regulation

This gives industry time to adapt while signalling a clear regulatory trajectory.

Summary and Next Steps

The DSIT Code represents a significant maturation of the UK’s approach to cyber resilience. Unlike its CRT predecessor, which was valuable but ultimately underpowered, this Code has the potential to meaningfully improve the safety and trustworthiness of enterprise-connected devices.

But for it to succeed, it must:

• Be risk-tiered
• Be economically incentivised
• Be pragmatically testable
• Be clearly scoped
• Include lifecycle-end protections
• Be usable by those who most need it

Security does not end at design, nor does it start at the point of compromise. By embedding these principles into our procurement decisions, product design, and ultimately our regulatory frameworks, the UK can lead the world in enterprise IoT security, just as we once did in defining the principles of secure software and consumer safety.

Let’s not waste this opportunity.

Summary of Recommendations

Recommendation	Rationale
Risk-based tiering	Enables proportional compliance, avoids overburdening low-risk devices
Procurement & insurance alignment	Creates economic incentive for vendors to adopt the Code
Lightweight assurance model	Enables transparency without costly certification
Clarified scope and definitions	Prevents ambiguity and misapplication
Secure decommissioning principle	Addresses lifecycle blind spots
SME-friendly materials	Ensures broader accessibility and adoption
Staged legislative pathway	Balances innovation, adaptation, and enforceability

If you’re a policymaker, manufacturer, buyer, or cyber strategist: the time to shape this Code is now. DSIT is listening. Let’s make sure we speak with insight and urgency.

Reflections from the Review Process

I had the privilege of contributing to the development of this Code as part of the national review process. This article reflects my own feedback and analysis, both as an individual expert and on behalf of the West Midlands Cyber Working Group (WM CWG). Our collective aim has been to ensure that the DSIT Code not only raises the bar technically, but does so in a way that is implementable, proportionate, and future-proof.

As the UK continues to strengthen its cyber resilience posture, this Code represents a real opportunity to lead by example on enterprise IoT. The feedback gathered now will shape not only regulatory direction but also the long-term trustworthiness of our national infrastructure. I hope these reflections help to inform that process.