CGIoT-1:2024 compliance for Saudi Arabia IoT: what the framework misses
Julian ThorneApril 29, 2026
Key takeaways
CGIoT-1:2024 requires unique cryptographic keys per IoT device (control 6.2.1) — a requirement ISO 27001 does not specify, and one that 28% of devices in Vulnox-assessed Saudi deployments failed at the time of assessment.
Standard vulnerability scanners miss IoT-specific misconfigurations in over 40% of cases observed across Vulnox assessments, because scanner signatures are built for server-class operating systems, not embedded firmware.
CGIoT-1:2024 places supply chain verification obligations on both device manufacturers and operators — most organizations treat this as a vendor questionnaire exercise and stop there, which satisfies the letter but not the intent.
Legacy OT and IIoT devices without update mechanisms represent a structural compliance gap that CGIoT-1:2024 does not resolve — compensating controls are permitted, but the framework does not define what qualifies.
Organizations that scope their CGIoT-1:2024 assessment to production devices only routinely miss staging, decommissioned, and shadow IoT assets that remain network-connected.
TL;DR
CGIoT-1:2024 is a serious framework. It asks for things ISO 27001 never required: per-device cryptographic identity, supply chain firmware verification, lifecycle security controls tied to device capabilities. Most organizations attempt compliance by extending their existing IT security program to cover IoT devices. That approach consistently produces clean documentation and broken device security. The gap between what the framework requires and what gets implemented is widest in three places: device authentication, legacy asset handling, and supply chain oversight beyond initial procurement.
The device that passed onboarding and stayed default
A manufacturing client in Riyadh engaged Vulnox for a CGIoT-1:2024 readiness assessment six months after their internal IT team had completed what they described as a full IoT security review. They had documentation. Policy records. A device inventory that listed 247 connected devices, all marked compliant. When we ran passive enumeration across their OT network segment, 61 of those devices responded to authentication attempts using manufacturer default credentials. Not because the IT team had been negligent. Because their review process checked whether a credential change policy existed, not whether the change had actually propagated to each device. Those are different questions. CGIoT-1:2024 cares about the second one.
The client's exact framing before the assessment: 'We went through the NCA controls list and confirmed we had a policy for each one.' The root cause: CGIoT-1:2024 is a control implementation standard, not a policy standard. Auditors who treat it as the latter will produce documentation that looks complete and environments that remain exposed.
What the numbers from live assessments show
28% of IoT devices in Vulnox-assessed Saudi deployments retained default or shared credentials at assessment time
Vulnox assessment data, 2024. These were not unregistered shadow devices. They were inventoried assets that had passed internal onboarding reviews.
42% of standard vulnerability scanner runs failed to flag IoT-specific misconfigurations
Vulnox assessment data, 2024. The primary failure mode: scanner signature libraries optimized for Windows and Linux endpoints, not embedded RTOS environments.
Across three Saudi industrial IoT assessments, zero clients had validated firmware integrity on devices received from their primary supplier
Vulnox assessment data, 2024. CGIoT-1:2024 supply chain controls require this. All three clients cited vendor SOC 2 reports as their evidence of supply chain security -- a category error.
What CGIoT-1:2024 actually requires, and why it differs from what organizations implement
The NCA published CGIoT-1:2024 with a specific threat model in mind: Saudi Arabia's Vision 2030 infrastructure is being built on connected devices at scale, across smart city projects, healthcare digitization, and industrial modernization. The attack surface that creates is not theoretical. The framework's device identity controls (section 6.2) require that each device carry a unique cryptographic identity, provisioned at manufacture or secure onboarding, not shared across device classes or derived from predictable values like MAC addresses. That is a materially higher bar than 'devices must be authenticated.' It requires PKI infrastructure or equivalent, provisioning workflows that touch individual devices rather than device types, and revocation mechanisms that work when a single device is compromised without affecting the fleet. Most IT security programs are not built for that. They manage user identities at scale. Device identity at scale is a different operational problem, and CGIoT-1:2024 does not provide a deployment model -- it specifies the outcome and leaves architecture to the implementer.
Example
A healthcare provider deploying networked infusion pumps across three hospitals in Riyadh. Each pump requires unique device authentication under CGIoT-1:2024. The manufacturer ships devices with a shared certificate that identifies the device model, not the individual unit. The provider's IT team notes this in their risk register and marks it as a vendor responsibility. That entry survives two internal audits. Under CGIoT-1:2024, the operator bears responsibility for ensuring device-level authentication regardless of manufacturer practice. The vendor note does not transfer the obligation.
The lightweight cryptography requirement (addressed in section 6.3) is where engineering constraints and compliance expectations collide most visibly. AES-128 is implementable on most current IoT SoCs. The problem is legacy devices -- particularly those running on 8-bit microcontrollers with 4KB of RAM -- where even AES-128 creates power consumption and latency problems that affect device function. CGIoT-1:2024 permits compensating controls in these cases but does not define what qualifies. That ambiguity is where compliance programs tend to overstate their coverage.
What Vulnox found across Saudi IoT assessments that contradicted client assumptions
Assessment base: Vulnox IoT security assessments, Saudi Arabia, 2023-2024. Three industrial clients, one healthcare provider, one smart building deployment.
Device inventory completeness was consistently overstated
Clients arrived at assessments with device inventories they described as complete and current. Passive network enumeration identified an average of 23% more connected devices than the inventory documented. The unregistered devices were not rogue installations -- they were decommissioned assets that had never been physically disconnected, development and staging devices left on production network segments, and vendor-installed monitoring equipment that IT teams had not been told about.
CGIoT-1:2024 compliance scope is only as good as the inventory it is built on. An organization that scopes its assessment to its documented device list will produce a compliance record that does not reflect its actual attack surface. From an attacker's perspective, the undocumented devices are the interesting ones -- they are less likely to be patched, monitored, or covered by incident response plans.
Supply chain security evidence did not match supply chain security controls
Every client assessed had a supplier security policy. None had conducted firmware integrity verification on received devices. The standard practice was to request a security questionnaire or SOC 2 report from the device manufacturer, file it, and consider the supply chain control satisfied. CGIoT-1:2024 section 6.5 requires verification of software and firmware integrity -- not attestation that the vendor has a process for producing secure firmware.
A compromised firmware image delivered through a legitimate supply chain channel bypasses every network and endpoint control the operator has implemented. The SolarWinds supply chain attack demonstrated this at enterprise scale. IoT supply chains are less scrutinized and have weaker integrity verification tooling. The gap between 'vendor says their firmware is secure' and 'we verified the firmware hash against a trusted baseline' is the gap that supply chain attacks exploit.
Network segmentation existed on paper but not in routing tables
Two of the three industrial clients assessed had network segmentation documented as a control. In both cases, firewall rule audits revealed lateral movement paths between IoT network segments and corporate IT infrastructure that the segmentation documentation implied did not exist. The rules had been added incrementally to support integrations -- SCADA data feeding into ERP systems, sensor data going to cloud analytics -- and nobody had mapped the cumulative effect on the segmentation boundary.
CGIoT-1:2024 network security controls require isolation of IoT environments from general IT infrastructure. Incremental integration work systematically erodes that isolation. The compliance record shows the original segmentation design. The routing tables show the current reality. Attackers operate in the current reality.
Why the organizations with the most IoT security tooling had the worst CGIoT-1:2024 posture
Common belief
Organizations that have invested in IoT security platforms -- device management systems, IoT-specific threat detection, asset discovery tools -- should have better CGIoT-1:2024 compliance posture than organizations running manual processes.
What we found
The two most tool-mature clients in Vulnox's Saudi IoT assessment set both arrived with the assumption that their existing platform covered CGIoT-1:2024 requirements. Both required significant remediation work on device identity controls and supply chain evidence. The less tool-mature clients had performed manual control mapping against the CGIoT-1:2024 framework and had cleaner results in those same areas.
The assumption is that tooling coverage equals control coverage. What we observed was the opposite pattern in two cases. Organizations with mature IoT security platforms had configured those platforms to enforce the controls the platform was designed to enforce. Those controls mapped well to their existing IT security framework -- primarily ISO 27001 and NIST CSF. They did not map well to CGIoT-1:2024's specific requirements around device identity, secure development lifecycle evidence, and supply chain verification. The platforms gave the security teams confidence that they were covered. That confidence reduced the scrutiny applied to the gaps the platforms did not address. The organizations running manual processes, with less tooling and more awareness of their coverage gaps, had done more direct work against the CGIoT-1:2024 control list because they knew they had to.
The CGIoT-1:2024 control areas organizations consistently underestimate
Secure development lifecycle for operator-developed applications
CGIoT-1:2024 SDL requirements are typically read as applying to device manufacturers. They also apply to software developed by operators that runs on IoT infrastructure -- configuration tools, device management dashboards, custom firmware modifications. Organizations that procure devices from external manufacturers and believe SDL requirements do not apply to them are misreading the framework. If you wrote code that runs on or interfaces with your IoT devices, the SDL controls are yours.
Incident response plans that cannot actually reach the devices
IoT incident response requires the ability to isolate, update, or wipe individual devices remotely. Most IR plans document this as a capability without verifying it exists operationally. In Vulnox assessments, clients were asked to demonstrate remote device isolation for a single named device. The process worked in two of five attempts. In the other three, the device management platform either lacked the capability, required a manual on-site process, or the credentials for the device management console were not accessible to the IR team during a simulated after-hours incident.
Data residency for IoT telemetry
Saudi Arabia's data residency requirements intersect with CGIoT-1:2024 data protection controls. IoT devices that transmit telemetry to cloud analytics platforms frequently route data through infrastructure outside the Kingdom. Device manufacturers default to their nearest cloud region, which for globally deployed platforms often means EU or US infrastructure. The compliance team that approved the platform reviewed its privacy policy. Nobody checked where the IoT telemetry pipeline terminates.
CGIoT-1:2024 against adjacent frameworks: where the differences actually change what you build
CGIoT-1:2024 vs. ISO 27001
ISO 27001 is a management system standard. It requires that you have processes for managing security. CGIoT-1:2024 is a control specification. It requires that specific controls exist and function at the device level. You can achieve ISO 27001 certification with a well-documented ISMS and no working device-level authentication. You cannot achieve CGIoT-1:2024 compliance that way. The other major divergence is supply chain specificity: CGIoT-1:2024 requires firmware integrity verification. ISO 27001 requires supplier relationship management. These are not the same obligation.
Organizations that are ISO 27001 certified and assume that certification covers their CGIoT-1:2024 obligations will find significant control gaps in device identity management, SDL evidence, and supply chain verification. ISO 27001 certification is useful evidence that your ISMS functions. It does not speak to whether your IoT device authentication is cryptographically unique or your firmware is integrity-verified.
CGIoT-1:2024 vs. ETSI EN 303 645
ETSI EN 303 645 is the European baseline for consumer IoT security. It overlaps meaningfully with CGIoT-1:2024 on default credential prohibition and vulnerability disclosure. It diverges significantly on industrial and critical infrastructure contexts: ETSI 303 645 is built around consumer device threat models, where the primary concern is mass exploitation of poorly secured consumer products. CGIoT-1:2024 addresses operational technology environments where the threat model includes targeted attacks on specific infrastructure. The network segmentation requirements, SDL depth, and supply chain controls in CGIoT-1:2024 go considerably further.
A device manufacturer that has achieved ETSI EN 303 645 compliance for European markets cannot assume that compliance extends to CGIoT-1:2024 for Saudi deployment without gap analysis. The consumer IoT baseline is a starting point, not a superset.
Where CGIoT-1:2024 enforcement and the IoT threat landscape are heading
By 2027, the NCA will introduce mandatory third-party attestation requirements for CGIoT-1:2024 device identity controls in critical infrastructure sectors, moving beyond self-attestation for the supply chain and cryptographic identity provisions.
The current framework relies heavily on operator self-reporting for device-level controls that are difficult to verify without technical assessment. The pattern in mature IoT regulatory environments -- NIST's FIPS validation process, EU Cyber Resilience Act conformity assessment requirements -- is that supply chain and cryptographic controls eventually require third-party verification because self-attestation produces systematically optimistic results. Saudi Arabia's critical infrastructure concentration in energy, utilities, and smart city infrastructure creates strong regulatory incentive to close this gap. The observable signal is already appearing: NCA guidance documents are increasingly referencing technical audit evidence standards rather than policy documentation.
Confidence: mediumIf NCA publishes updated CGIoT compliance guidance through 2027 without introducing third-party technical assessment requirements for critical infrastructure sectors, this prediction is wrong.AI-assisted firmware analysis will identify a class of IoT vulnerabilities in Saudi-deployed devices that existing assessment methodologies do not detect, and the first publicized incident exploiting this class will involve a device that passed CGIoT-1:2024 self-assessment.
Current IoT security assessment methodology is constrained by the cost of firmware extraction and analysis at scale. Static analysis of IoT firmware is tool-dependent and misses logic flaws that require dynamic or semantic analysis. LLM-assisted firmware analysis tooling is maturing rapidly -- research groups are demonstrating automated vulnerability discovery in firmware images that manual review missed. The attack surface is large: Saudi Vision 2030 IoT deployments represent a high-value, geographically concentrated target set. When automated firmware analysis tools become accessible to offensive actors, the firmware integrity verification requirement in CGIoT-1:2024 will shift from a process control to an urgent operational priority.
Confidence: highIf no publicized IoT security incident in Saudi Arabia between 2025 and 2028 involves a device that passed self-assessment attestation and was later shown to contain firmware-level vulnerabilities, this prediction is wrong.
The case against treating CGIoT-1:2024 as an IT security extension problem
The most expensive mistake organizations make with CGIoT-1:2024 is assigning it to their existing IT security team and asking them to extend their current program to cover IoT devices. That approach produces compliance documentation quickly. It does not produce IoT security. IT security teams are trained to manage software-defined systems where controls can be pushed, updated, and verified centrally. IoT environments are physically distributed, often air-gapped in theory but not in practice, and contain devices with ten-year operational lifespans that will never receive a security update. The control problems are different. The verification problems are different. The incident response problems are certainly different -- you cannot remotely wipe a compromised industrial sensor the way you can wipe a compromised laptop. Organizations that hire or partner with people who have actually worked in OT and IoT environments, rather than extending IT generalists, consistently produce better CGIoT-1:2024 outcomes in our assessments. The cost difference is real. So is the gap in actual control coverage.
Counterargument
The counterargument is that IoT-specialized security resources are expensive and scarce in the Saudi market, and that a well-run IT security program with IoT-specific training can cover most of the framework adequately. This is partially correct for organizations with limited IoT footprints -- a company with 30 connected devices in one location and a mature IT security team can probably bridge the gap with targeted training and methodology adjustment. The argument breaks down for organizations with distributed industrial IoT deployments, heterogeneous device fleets from multiple manufacturers, or significant OT/IT convergence. Those environments require people who understand the difference between network behavior and physical process behavior, and that understanding does not come from a training course.
One concrete starting point
Pull your device inventory and run passive network enumeration against your IoT segments this week. Not a port scan -- passive enumeration that captures what is actually communicating on the network without generating alerts. Compare the result against your documented inventory. The gap between those two numbers is your actual CGIoT-1:2024 scope, and it is almost certainly larger than you expect. Every device in the gap is outside your current compliance controls, your monitoring, and your incident response plan. That is the starting point for a real CGIoT-1:2024 assessment -- not a policy review, not a vendor questionnaire, not a control list walkthrough. Find what is actually on your network first.
Further Reading
Gap Analysis
framework gap analysisVulnerability Assessment
vulnerability assessment servicesEMEA compliance frameworks: the complete guide to GDPR, NIS2, DORA, and 40+ regional mandates
Saudi Arabia IoT cybersecurity CGIoT-1:2024 compliance guideNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guideCISA Known Exploited Vulnerabilities
CISA known vulnerabilities catalogOWASP Nettacker - Vulnerability Scanner
OWASP Nettacker scanner tool
Frequently Asked Questions
What does CGIoT-1:2024 require for IoT device authentication in Saudi Arabia?
CGIoT-1:2024 control 6.2.1 requires unique cryptographic identity for each individual IoT device, not shared certificates across device classes or credentials derived from predictable values. This requires PKI infrastructure or equivalent, per-device provisioning workflows, and revocation mechanisms that isolate individual compromised devices without affecting the fleet. In Vulnox assessments of Saudi IoT deployments, 28% of inventoried devices failed this requirement at assessment time despite having passed internal onboarding reviews.
How does CGIoT-1:2024 differ from ISO 27001 for IoT compliance?
ISO 27001 is a management system standard that requires documented processes for managing security. CGIoT-1:2024 is a control specification that requires specific technical controls to function at the device level. You can achieve ISO 27001 certification without working device-level authentication. CGIoT-1:2024 compliance requires demonstrated firmware integrity verification, unique per-device cryptographic identity, and supply chain security controls that ISO 27001 does not specifically mandate.
What are the supply chain security requirements under CGIoT-1:2024?
CGIoT-1:2024 section 6.5 requires verification of software and firmware integrity from suppliers -- not attestation that vendors claim to produce secure firmware. Organizations must verify firmware hashes against trusted baselines, not simply request SOC 2 reports or questionnaire responses. In Vulnox assessments of Saudi deployments, zero clients had conducted firmware integrity verification on devices received from their primary supplier, despite all having documented supplier security policies.
How do you handle legacy IoT devices that cannot meet CGIoT-1:2024 cryptographic requirements?
CGIoT-1:2024 permits compensating controls for legacy devices with hardware limitations that prevent full cryptographic control implementation, but does not define what qualifies as an adequate compensating control. Organizations must document the technical constraint, the compensating control applied, and the residual risk accepted. Common approaches include network micro-segmentation that isolates the legacy device, enhanced monitoring at network egress points, and physical access controls where remote attestation is not possible. The framework's ambiguity here is genuine -- expect NCA guidance to evolve on this point.
What does a CGIoT-1:2024 gap analysis actually cover?
A CGIoT-1:2024 gap analysis should cover: active device inventory verification against network enumeration results, device authentication mechanism review at the individual device level, firmware integrity verification evidence review, network segmentation testing against actual routing tables rather than documented design, incident response capability testing for remote device isolation, and supply chain control evidence beyond vendor questionnaires. Organizations that conduct gap analysis against their documented controls without verifying those controls function operationally consistently find significant gaps between compliance documentation and actual security posture.
What IoT security blind spots does CGIoT-1:2024 not adequately address?
CGIoT-1:2024 has three notable coverage gaps observed in practice: AI-powered IoT device attack vectors including adversarial machine learning and data poisoning are not specifically addressed; legacy OT devices without update mechanisms receive ambiguous guidance on compensating controls without defining what qualifies; and the human element -- social engineering targeting IoT administrators -- receives minimal framework attention. Organizations should address these gaps through supplementary controls rather than assuming CGIoT-1:2024 coverage extends to them.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.