NCA CGIoT: Internet of Things Security Guidelines

The Cybersecurity Guidelines for Internet of Things (CGIoT – 1: 2024) are the NCA's answer to a class of asset that fits badly into every other framework it publishes. IoT devices are too numerous for an asset register that assumes servers, too constrained for standard cryptography, often unpatched by design, and frequently procured by facilities or operations rather than IT.

The guidelines are non-mandatory — the only document in this part of the NCA catalogue that says so explicitly — but they are structured exactly like the mandatory control sets, which makes them straightforward to fold into an existing programme.

What the CGIoT covers

The NCA defines IoT as sensors and devices ("things") connected to the internet and/or other networks, creating value from exchanged data. The named use cases are smart homes, smart cities, smart healthcare and smart cars.

They were developed after studying international IoT cybersecurity guidelines, standards, frameworks and controls, analysing national initiatives and regulatory requirements, and reviewing previous IoT incidents and attacks. Like the NCA's control sets, they address four pillars: Strategy, People, Processes and Technology.

That boundary is the first decision in any CGIoT programme: sort the estate into industrial IoT (OTCC, mandatory, level-tiered) and everything else (CGIoT, advisory). Building sensors, smart lighting, connected cameras, medical devices and fleet telematics generally fall on the CGIoT side; anything attached to an industrial control system does not.

The four domains

Three subdomains in Domain 2 have no equivalent in the ECC: IoT-connected mobile device security, IoT application security, and — the one that matters most operationally — IoT device lifecycle management. Everything else maps onto an ECC subdomain your programme already covers.

Resilience: devices that keep working when the network does not

Domain 3 contains only two guidelines, and both are unusual enough to quote.

3-1-1 requires resiliency requirements for IoT device confidentiality, integrity and availability to be defined, documented, approved and implemented as part of the organisation's BCM plan, and reviewed periodically — including:

• developing resiliency requirements considering how disruption of a device's essential functions by a cyberattack would affect the business operations associated with it;
• implementing resilience measures proportionate to the intended usage of the device, considering other components of the IoT system or service;
• ensuring essential cybersecurity functions of IoT devices and services can function locally during a network or power outage and return to a desired state afterwards.

3-1-2 goes further: IoT endpoint devices, especially gateway devices, must be capable of enforcing cybersecurity over communication networks and protocols even during a connectivity outage or disruption to the back-end network, where applicable.

This is the guideline that separates IoT security from IT security. A laptop that loses connectivity stops being useful. A door controller, a valve actuator or a patient monitor that loses connectivity keeps operating — and must keep enforcing its security controls while unsupervised.

Local enforcement during a back-end outage is an architecture requirement, and it needs to be a procurement question. It cannot be added to a device that was not built for it, which is why it belongs in the BCM programme and the purchasing specification rather than in an operational runbook.

Third-party and supply chain

Domain 4 is where most organisations will find their real gaps, because IoT risk is overwhelmingly inherited from manufacturers.

4-1 Third-Party Cybersecurity asks organisations to define, document, approve and implement IoT cybersecurity requirements in contracts with supply chain partners and third parties (4-1-1), and then to:

• 4-1-2 — request manufacturers and service providers to demonstrate the cybersecurity capabilities in their products and services and to implement 'Secure-by-Design' principles throughout the development lifecycle.
• 4-1-3 — request developers and manufacturers to provide a list of hardware and software components in the devices and services, to support risk management and patching of known vulnerabilities.
• 4-1-4 — identify IoT systems, components and services supplied by third parties for inclusion in the overall risk assessment.
• 4-1-5 — implement verification through audits, testing and software certification assurance that third-party components meet the organisation's policies and contract requirements.
• 4-1-6 — periodically review third-party IoT risk mitigation procedures to detect unauthorised procedures.

Guideline 4-1-3 is, in substance, a software and hardware bill of materials requirement. Asking for it at procurement is the difference between being able to answer "are we exposed to this CVE?" in an hour and not being able to answer it at all.

4-2 Cloud Computing and Hosting Cybersecurity covers the back end. It requires cybersecurity requirements for cloud services hosting IoT services to be defined and periodically reviewed including the applicable Cloud Cybersecurity Controls (4-2-1); adequate authorisation, authentication, verification and encryption for devices interacting with private, self-hosted or other IoT cloud services (4-2-2); assessment of the CSP's or MSP's cybersecurity posture against the organisation's IoT policies (4-2-3); procedures enabling audits, monitoring of IoT-specific data manipulation, and management of multi-tenant risks (4-2-4); and contractual provisions to obtain data stored on cloud platforms in a vendor-neutral format on planned or unplanned exit (4-2-5).

That last one is a genuine exit-risk control. IoT telemetry accumulates in provider-specific formats, and a platform migration without a neutral-format clause means either losing the history or paying whatever the incumbent asks.

The eleven manufacturer principles

Appendix A sets out principles the NCA encourages IoT manufacturers to follow when developing products and services. They are the specification to attach to a tender.

Principle 4 is unusually specific for a guidance document, and it is the most useful one in a hardware evaluation: a device whose embedded system has no MMU or MPU cannot enforce memory protection, and that constraint should be known before purchase rather than discovered during a penetration test.

How to adopt the CGIoT

1. Split the estate. Industrial IoT to the OTCC (mandatory, facility-level-tiered); everything else to the CGIoT.
2. Find the devices. IoT is routinely procured outside IT. Facilities, clinical engineering, logistics and marketing all buy connected things. Domain 2's asset management subdomain starts here.
3. Stand up device lifecycle management. Onboarding, credential rotation, firmware updates, monitoring and — critically — decommissioning. The lifecycle subdomain has no ECC equivalent, so there is no existing process to extend.
4. Attack default credentials first. Manufacturer principle 5 exists because default and hard-coded passwords remain the single most exploited IoT weakness.
5. Add the CGIoT requirements to contracts — Secure-by-Design attestation, the component list, the patch-timeliness commitment, and the vendor-neutral data export clause for the cloud back end.
6. Test the offline case. Confirm which devices continue to enforce their controls when the back-end network is unavailable, and record the ones that do not as risks on the NFCRM matrix.
7. Fold IoT into the BCM plan rather than treating device resilience as a separate exercise.

How GRC Vantage supports IoT governance

GRC Vantage's compliance module carries the CGIoT as an assessable set alongside the mandatory NCA controls, with each guideline mapped to its ECC or OTCC counterpart so an IoT assessment reuses the evidence your programme already produces rather than starting a parallel one. Devices are held in the asset register with their classification, their network exposure and their industrial-versus-generic split, so the OTCC boundary is recorded rather than argued about.

Manufacturer and platform obligations under Domain 4 — Secure-by-Design attestation, the hardware and software component list, patch timeliness, and the vendor-neutral export clause — run through the vendor workflow against the contract that carries them, with periodic review under 4-1-6 scheduled as an evidence-bearing task.

For the full family, see the NCA frameworks pillar guide. To scope IoT governance across a mixed estate, talk to our team.

Frequently asked questions

What is the NCA CGIoT?

The Cybersecurity Guidelines for Internet of Things (CGIoT – 1: 2024) are the NCA's recommended cybersecurity practices for organisations using IoT technologies in Saudi Arabia. They comprise 4 main domains, 27 subdomains and 81 guidelines, plus 11 cybersecurity principles for IoT manufacturers in Appendix A.

Are the CGIoT guidelines mandatory?

No. The NCA states the main objective is to provide non-mandatory guidance based on industry-leading standards, recommended for application in all organisations across the Kingdom that use IoT technologies.

Do the CGIoT apply to industrial IoT?

No. The CGIoT are generic IoT guidelines. The NCA states that Industrial IoT should comply with the Operational Technology Cybersecurity Controls (OTCC-1:2022), which are mandatory for Industrial Control Systems in critical facilities.

What do the CGIoT require of IoT manufacturers?

Appendix A sets out eleven guiding principles, including applying Secure-by-Design and Secure-by-Default throughout the development lifecycle, eliminating default and hard-coded passwords, designing embedded systems with Memory Management and Memory Protection Units, providing a component list including third-party dependencies, minimising the gap between vulnerability discovery and patch release, and informing consumers when a security update is needed and what risks it mitigates.

What do the CGIoT say about IoT devices during a network outage?

Guideline 3-1-1 requires essential cybersecurity functions of IoT devices and services to be capable of functioning locally during a network or power outage and returning to a desired state afterwards, and 3-1-2 requires IoT endpoint devices — especially gateways — to enforce cybersecurity over communication networks and protocols even when connectivity to the back-end network is disrupted.