1394  IoT Security Compliance Frameworks

1394.1 IoT Security Compliance Quick Reference

Time: ~20 min | Level: Intermediate

Understanding threats and vulnerabilities is essential, but demonstrating compliance with security standards is often required for IoT deployments in regulated industries. This section provides practical guidance on major security compliance frameworks and their application to IoT systems.

WarningSecurity Compliance Framework Comparison

Different industries and regions require compliance with specific security standards:

Framework	Scope	IoT Relevance	Key Requirements	Certification Required	Industry Focus
NIST Cybersecurity Framework	US federal agencies + voluntary adoption	High - comprehensive IoT guidance	Identify, Protect, Detect, Respond, Recover	No (self-assessment)	Cross-industry
ISO/IEC 27001	Information security management	High - applies to all IT/IoT systems	ISMS, risk assessment, security controls	Yes (3rd party audit)	Cross-industry
IEC 62443	Industrial control systems	Critical for IIoT	Security levels (SL 1-4), zone segmentation	Yes (component/system certification)	Industrial IoT, OT
ETSI EN 303 645	Consumer IoT security	Very high - designed specifically for IoT	13 provisions (no default passwords, secure updates, etc.)	No (self-declaration)	Consumer IoT devices
FDA Cybersecurity	Medical device security	Critical for medical IoT	Premarket guidance, SBOM, updates, threat modeling	Yes (FDA approval)	Healthcare IoT
UL 2900-1	Software cybersecurity	High for connected products	Vulnerability testing, known vulnerability assessment	Yes (UL certification)	Consumer electronics, IoT
FIPS 140-2/3	Cryptographic modules	Critical for government/regulated use	Cryptographic algorithm and implementation validation	Yes (NIST validation)	Government, financial, healthcare
PCI DSS	Payment card data security	Medium for payment IoT	Secure network, encryption, access control	Yes (QSA audit)	Retail IoT, payment terminals

1394.2 NIST Cybersecurity Framework for IoT

The National Institute of Standards and Technology (NIST) provides comprehensive IoT security guidance through multiple publications, with the Cybersecurity Framework being widely adopted across industries.

1394.2.1 NIST Cybersecurity Framework Core Functions

The framework organizes security activities into five concurrent and continuous functions:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '13px'}}}%%
graph LR
    I[Identify<br/>Assets, risks,<br/>governance]
    P[Protect<br/>Safeguards,<br/>access control]
    D[Detect<br/>Anomalies,<br/>monitoring]
    R[Respond<br/>Response planning,<br/>mitigation]
    Re[Recover<br/>Recovery planning,<br/>improvements]

    I --> P --> D --> R --> Re
    Re -.-> I

    style I fill:#2C3E50,stroke:#16A085,color:#fff
    style P fill:#16A085,stroke:#0e6655,color:#fff
    style D fill:#E67E22,stroke:#d35400,color:#fff
    style R fill:#e74c3c,stroke:#c0392b,color:#fff
    style Re fill:#9B59B6,stroke:#8e44ad,color:#fff

Figure 1394.1: NIST Cybersecurity Framework five core functions showing continuous security lifecycle.

1394.2.2 IoT-Specific Implementation Guide (NIST IR 8259)

Capability	IoT Implementation	Example
Device Identification	Unique device identifier, asset type, manufacturer details	Serial number, model number, firmware version API
Device Configuration	Logical/physical interfaces, configuration settings management	REST API for configuration, documented default settings
Data Protection	Encryption of data at rest and in transit	TLS 1.3 for communications, AES-256 for storage
Logical Access to Interfaces	Authentication, authorization, access control lists	Certificate-based auth, role-based access control (RBAC)
Software/Firmware Update	Secure update mechanism with integrity verification	Signed firmware updates, version rollback capability
Cybersecurity State Awareness	Event logging, security posture monitoring	Syslog to SIEM, tamper detection alerts

1394.2.3 NIST Compliance Checklist for IoT Manufacturers

TipNIST IoT Device Compliance Requirements

Device Identification (ID)

• Unique device identifier (cryptographically secure)
• Device asset type and manufacturer information
• Model number and serial number
• Current software/firmware version
• Hardware version and revision

Device Configuration (DC)

• Document all logical and physical interfaces
• Configuration management capability
• Ability to change security settings
• Configuration backup and restore
• Factory reset capability

Data Protection (DP)

• Encrypt sensitive data at rest (AES-256)
• Encrypt data in transit (TLS 1.3/DTLS 1.3)
• Secure key storage (TPM, Secure Enclave)
• Cryptographic algorithm compliance (FIPS 140-2)
• Data sanitization on decommissioning

Logical Access (LA)

• Authentication required for all interfaces
• Strong password/passphrase requirements
• Multi-factor authentication support
• Role-based authorization (RBAC)
• Session management and timeout

Software/Firmware Updates (SU)

• Secure update mechanism (signed updates)
• Update integrity verification
• Update authenticity verification
• Update versioning and rollback
• Notification of available updates
• Ability to defer/schedule updates

Cybersecurity State Awareness (SA)

• Security event logging
• Log integrity protection
• Integration with enterprise SIEM
• Tamper detection and alerting
• Self-test and diagnostics

1394.2.4 NIST 800-53 Security Controls for IoT

For federal systems, NIST SP 800-53 defines comprehensive security controls:

Control Family	Example Controls	IoT Application
AC - Access Control	AC-2 (Account Management), AC-7 (Unsuccessful Logon Attempts)	Unique device accounts, lockout after failed auth
AU - Audit and Accountability	AU-2 (Event Logging), AU-9 (Protection of Audit Information)	Log all security events, protect logs from tampering
CM - Configuration Management	CM-3 (Configuration Change Control), CM-7 (Least Functionality)	Change management for firmware updates, disable unused services
IA - Identification and Authentication	IA-2 (User Identification), IA-5 (Authenticator Management)	Certificate-based device identity, secure credential storage
SC - System and Communications Protection	SC-8 (Transmission Confidentiality), SC-13 (Cryptographic Protection)	TLS/DTLS for communications, FIPS-approved algorithms
SI - System and Information Integrity	SI-2 (Flaw Remediation), SI-3 (Malicious Code Protection)	Timely patching, malware detection on gateway

1394.3 ETSI EN 303 645 - Consumer IoT Security

The European standard EN 303 645 defines 13 security provisions specifically for consumer IoT devices. This is becoming a global baseline for IoT security.

1394.3.1 The 13 Provisions

#	Provision	Requirement	IoT Implementation	Verification
1	No default passwords	Unique passwords per device OR user-set password on first use	Generate unique password per device, printed on label	Test: Can device be accessed with default credentials?
2	Implement vulnerability disclosure policy	Public contact point for security researchers	security@company.com, HackerOne program	Test: Is security contact publicly documented?
3	Keep software updated	Security updates for defined support period	OTA updates, automatic update mechanism	Test: Can device receive and install updates?
4	Securely store sensitive data	Encrypt credentials and personal data	AES-256 encryption for stored passwords, keys in Secure Element	Test: Extract firmware and search for plaintext secrets
5	Communicate securely	Use TLS/DTLS for network communications	TLS 1.3 with certificate validation, no plaintext protocols	Test: Packet capture shows encrypted traffic
6	Minimize exposed attack surfaces	Disable unused services, ports, protocols	Close unnecessary ports, disable debug interfaces in production	Test: Port scan reveals only required services
7	Ensure software integrity	Verify firmware authenticity before installation	Cryptographic signature verification, secure boot	Test: Can unsigned firmware be installed?
8	Ensure personal data is secure	Comply with data protection regulations (GDPR)	Encryption, access control, data minimization	Test: Review data collection and storage practices
9	Make systems resilient to outages	Graceful degradation, local operation capability	Device functions locally during internet outage	Test: Disconnect from internet, verify local operation
10	Examine system telemetry data	Monitor security events and anomalies	Log security events, integrate with SIEM	Test: Generate security event, verify logged
11	Make it easy for users to delete personal data	User-accessible data deletion mechanism	Factory reset, cloud account deletion with data removal	Test: Delete data, verify complete removal
12	Make installation and maintenance easy	Clear security guidance for users	Quick start guide includes security setup	Test: Review user documentation for security info
13	Validate input data	Sanitize all external input	Input validation, parameterized queries, buffer bounds checking	Test: Fuzz testing, SQL injection attempts

1394.3.2 ETSI Compliance Implementation Roadmap

TipETSI EN 303 645 Implementation Steps

Phase 1: Authentication & Access (Provisions 1, 6)

• Week 1-2: Eliminate default passwords
• Week 3-4: Disable unused network services
• Deliverable: Authentication specification document

Phase 2: Communication Security (Provisions 4, 5)

• Week 5-6: Implement TLS/DTLS for all communications
• Week 7-8: Encrypt sensitive data at rest
• Deliverable: Cryptographic architecture document

Phase 3: Software Integrity (Provisions 3, 7)

• Week 9-10: Design secure update mechanism
• Week 11-12: Implement firmware signature verification
• Deliverable: Update architecture and test results

Phase 4: Data Protection (Provisions 8, 11)

• Week 13-14: Implement GDPR-compliant data handling
• Week 15-16: Add user data deletion capability
• Deliverable: Privacy compliance documentation

Phase 5: Resilience & Monitoring (Provisions 9, 10)

• Week 17-18: Ensure local operation capability
• Week 19-20: Implement security event logging
• Deliverable: Resilience test report

Phase 6: User Experience & Vulnerability Management (Provisions 2, 12, 13)

• Week 21-22: Create user security documentation
• Week 23-24: Establish vulnerability disclosure program
• Week 25-26: Implement comprehensive input validation
• Deliverable: User guide, security policy, validation test results

1394.3.3 Real-World ETSI Compliance Examples

Good Example: Philips Hue

• Provision 1: Requires user to set password on first setup
• Provision 3: Regular automatic firmware updates
• Provision 5: Encrypted communication with cloud services
• Provision 7: Signed firmware updates verified before installation

Bad Example: Many cheap IP cameras

• Provision 1: Ships with “admin/admin” default credentials
• Provision 3: No firmware update mechanism
• Provision 5: Streams video over unencrypted HTTP
• Provision 6: Exposes Telnet, FTP, unnecessary services

{
  const container = document.getElementById('kc-compliance-8');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "Your IoT device manufacturer wants to sell smart thermostats in the EU market starting in 2024. A port scan reveals the device has Telnet (port 23) and HTTP (port 80) open. Default login is 'admin/admin'. Which ETSI EN 303 645 provisions are violated?",
      options: [
        {text: "Only Provision 1 (No default passwords)", correct: false, feedback: "Default credentials violate Provision 1, but there are additional violations from the open ports and unencrypted HTTP."},
        {text: "Provisions 1 (Default passwords), 5 (Secure communication), and 6 (Minimize attack surface)", correct: true, feedback: "Correct! Provision 1 violated by 'admin/admin' default credentials. Provision 5 violated by HTTP (unencrypted) instead of HTTPS. Provision 6 violated by unnecessary Telnet port exposed. The device cannot legally be sold in the EU until all provisions are addressed."},
        {text: "Only Provision 6 (Minimize attack surface) - extra ports are open", correct: false, feedback: "Open ports violate Provision 6, but the default credentials and unencrypted HTTP are equally critical violations."},
        {text: "Provisions 3 (Software updates) and 7 (Software integrity)", correct: false, feedback: "The scenario doesn't provide information about update mechanisms. The violations are clearly 1, 5, and 6 based on what's described."}
      ],
      difficulty: "medium",
      topic: "iot-security"
    }));
  }
}

1394.4 IEC 62443 - Industrial IoT Security

IEC 62443 is the international standard for industrial automation and control system (IACS) security. Critical for IIoT deployments.

1394.4.1 Security Levels (SL)

IEC 62443 defines four security levels based on threat sophistication:

Security Level	Threat Description	Attacker Profile	IIoT Example
SL 1	Protection against casual or coincidental violation	Unskilled individual with no specific target	Basic smart building controls
SL 2	Protection against intentional violation using simple means	Skilled individual with low resources, generic tools	Industrial sensors on corporate network
SL 3	Protection against intentional violation using sophisticated means	Skilled individual/group with moderate resources, custom tools	Critical infrastructure monitoring
SL 4	Protection against intentional violation using sophisticated means with extended resources	Highly skilled group with extensive resources (nation-state)	Nuclear plant control, military IIoT

1394.4.2 Zone and Conduit Model

IEC 62443 uses network segmentation for defense in depth:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '12px'}}}%%
graph TB
    subgraph "Internet Zone (SL1)"
    INT[Internet]
    end

    subgraph "DMZ Zone (SL2)"
    FW1[Firewall]
    DMZ[DMZ Servers]
    end

    subgraph "Enterprise Zone (SL2)"
    ENT[Enterprise Network]
    end

    subgraph "Control Zone (SL3)"
    FW2[Industrial Firewall]
    CTRL[Control Systems]
    end

    subgraph "Process Zone (SL4)"
    PLC[PLCs / RTUs]
    SENS[Sensors / Actuators]
    end

    INT --> FW1
    FW1 --> DMZ
    DMZ --> ENT
    ENT --> FW2
    FW2 --> CTRL
    CTRL --> PLC
    PLC --> SENS

    style INT fill:#7F8C8D,stroke:#5a6b6d,color:#fff
    style FW1 fill:#e74c3c,stroke:#c0392b,color:#fff
    style DMZ fill:#E67E22,stroke:#d35400,color:#fff
    style ENT fill:#2C3E50,stroke:#16A085,color:#fff
    style FW2 fill:#e74c3c,stroke:#c0392b,color:#fff
    style CTRL fill:#16A085,stroke:#0e6655,color:#fff
    style PLC fill:#2C3E50,stroke:#16A085,color:#fff
    style SENS fill:#2C3E50,stroke:#16A085,color:#fff

Figure 1394.2: IEC 62443 zone and conduit architecture showing hierarchical network segmentation.

1394.4.3 IEC 62443 Foundational Requirements

Requirement	Description	IIoT Implementation
FR 1: Identification and Authentication Control	Verify identity of users, processes, devices	Certificate-based device identity, multi-factor authentication for operators
FR 2: Use Control	Enforce authorization of user/device actions	Role-based access control (RBAC), least privilege principle
FR 3: System Integrity	Ensure system hasn’t been tampered with	Secure boot, firmware signature verification, file integrity monitoring
FR 4: Data Confidentiality	Protect sensitive data from disclosure	Encryption of data at rest and in transit (TLS, IPsec)
FR 5: Restricted Data Flow	Segment network, control data flows between zones	Firewalls, VLANs, unidirectional gateways
FR 6: Timely Response to Events	Detect and respond to security events	SIEM integration, automated alerting, incident response
FR 7: Resource Availability	Ensure system remains available under attack	DoS protection, redundancy, graceful degradation

{
  const container = document.getElementById('kc-iec62443-zones');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "An industrial facility implements IEC 62443 zone segmentation with PLCs in Zone 2 (SL3) and field sensors in Zone 3 (SL4). A security engineer proposes allowing a software vendor remote VPN access directly to Zone 3 for 'faster troubleshooting.' What is the PRIMARY security concern?",
      options: [
        {text: "VPN encryption may not be strong enough for industrial protocols", correct: false, feedback: "Modern VPNs use strong encryption. The issue is access control and zone boundary violation, not encryption strength."},
        {text: "The vendor might accidentally misconfigure sensors during troubleshooting", correct: false, feedback: "Operational errors are a concern but not the primary security issue with this architecture decision."},
        {text: "Direct remote access to highest-security zone bypasses defense-in-depth architecture", correct: true, feedback: "Correct! IEC 62443 zones exist to create defense-in-depth barriers. Zone 3 (SL4) has the highest security requirements precisely because it controls physical processes. Direct VPN access from the internet to Zone 3 bypasses all intermediate security controls. Proper architecture: VPN terminates in DMZ, vendor accesses jump host, then authenticated connection to Zone 2/3 with logging."},
        {text: "The vendor's computer might have malware that spreads to sensors", correct: false, feedback: "This is a valid concern but secondary. The primary issue is architectural - even a clean computer shouldn't have direct Zone 3 access."}
      ],
      difficulty: "hard",
      topic: "iot-security"
    }));
  }
}

1394.4.4 IEC 62443-4-2 Component Requirements Checklist

TipIEC 62443-4-2 Component Requirements

IAC - Identification and Authentication Control

• Unique identification for humans, software, devices
• Strength of password based on SL (SL 1: basic, SL 3: strong, SL 4: MFA)
• Account lockout after failed authentication attempts
• Re-authentication for privileged operations

UC - Use Control

• Authorization enforcement based on roles/permissions
• Least privilege principle applied
• Privilege escalation requires re-authentication
• Separation of duties for critical operations

SI - System Integrity

• Software/firmware updates must be authenticated and verified
• Detection of malicious code/unauthorized changes
• Secure boot process for SL 3+
• Configuration change detection and alerting

DC - Data Confidentiality

• Encryption of sensitive data at rest (SL 2+)
• Encryption of data in transit (SL 1+: basic, SL 3+: strong)
• Secure key management
• No hardcoded credentials or keys

RDF - Restricted Data Flow

• Zone-based network segmentation
• Ingress/egress filtering at zone boundaries
• Deny-by-default firewall rules
• Monitoring of data flows between zones

TRE - Timely Response to Events

• Audit logging of security events
• Real-time detection of security violations
• Automated alerting for critical events
• Integration with SIEM/security monitoring

RA - Resource Availability

• Protection against denial of service attacks
• Resource management (CPU, memory, bandwidth)
• Redundancy for critical components (if SL 3+)
• Graceful degradation under attack

1394.5 FDA Cybersecurity Guidance for Medical IoT

The U.S. Food and Drug Administration (FDA) provides cybersecurity guidance for medical devices, including IoT devices like insulin pumps, pacemakers, and remote patient monitoring systems.

1394.5.1 FDA Premarket Guidance (2023)

Requirement	Description	Example for IoT Medical Device
SBOM (Software Bill of Materials)	List of all software components including versions	Document all third-party libraries, OS components, open-source code
Cybersecurity Risk Management	Threat modeling and risk assessment	STRIDE analysis, attack tree, FMEA for cybersecurity
Security Architecture	Design features that protect device	End-to-end encryption, secure boot, access controls
Secure Software Development	Security in development lifecycle	Secure coding standards, code review, SAST/DAST testing
Vulnerability Management	Plan for handling discovered vulnerabilities	Vulnerability disclosure policy, coordinated disclosure process
Updates and Patches	Mechanism for deploying security updates	OTA update capability with authentication and integrity checks

1394.5.2 FDA Postmarket Requirements

TipFDA Postmarket Requirements

Monitoring & Detection

• Continuous monitoring for cybersecurity threats
• Vulnerability scanning and penetration testing
• Participation in ISAOs (Information Sharing and Analysis Organizations)
• Subscribe to ICS-CERT and vulnerability databases

Incident Response

• Cybersecurity incident response plan
• Report incidents to FDA via MedWatch (if patient impact)
• Root cause analysis for security incidents
• Corrective and Preventive Actions (CAPA)

Updates & Patches

• Security patch deployment within 30-60 days of critical vulnerability
• Change control process for security updates
• Regression testing to ensure update doesn’t break device
• User notification of critical security updates

Transparency

• Publish supported lifetime of device
• Clear end-of-life and end-of-support dates
• Public vulnerability disclosure with CVE assignment
• Coordinated disclosure with security researchers

1394.5.3 Medical IoT Specific Considerations

Unique Challenges:

1. Patient Safety: Cybersecurity fixes must not introduce safety risks
2. Legacy Devices: Many medical IoT devices remain in use 10-20 years
3. Interoperability: Must work with other medical devices, hospital networks
4. Regulatory Lag: Cybersecurity evolves faster than regulatory approval cycles

Example: Insulin Pump Security

• Threat: Unauthorized wireless control could deliver fatal insulin dose
• Mitigation: Encrypted communication, pairing mechanism, dosage limits, alerts for unusual activity
• Regulation: FDA premarket cybersecurity review, postmarket monitoring

{
  const container = document.getElementById('kc-stride-application');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "During STRIDE threat modeling for a connected vehicle system, you identify that the OBD-II diagnostic port allows any connected device to send CAN bus commands without authentication. An attacker could connect a malicious device and send 'disable brakes' commands. Which STRIDE categories does this vulnerability enable?",
      options: [
        {text: "Only Denial of Service - the brakes become unavailable", correct: false, feedback: "Disabling brakes is more than just unavailability - it's unauthorized control of safety-critical functions."},
        {text: "Only Tampering - the attacker modifies brake behavior", correct: false, feedback: "Tampering is involved, but the attack also involves unauthorized commands and impersonation."},
        {text: "Spoofing (unauthenticated commands), Tampering (modifying brake behavior), and Elevation of Privilege (safety-critical control)", correct: true, feedback: "Correct! Multiple STRIDE categories apply: (1) Spoofing - the malicious device impersonates legitimate diagnostic equipment, (2) Tampering - brake commands are modified/injected, (3) Elevation of Privilege - gaining control over safety-critical systems without authorization."},
        {text: "Information Disclosure - the attacker learns about brake status", correct: false, feedback: "The attack is about sending unauthorized commands, not reading information."}
      ],
      difficulty: "hard",
      topic: "iot-security"
    }));
  }
}

1394.6 Security Certification and Assessment Resources

1394.6.1 Third-Party Assessment Programs

Program	Focus	Benefits	Process
IoT Security Foundation (IoTSF) Compliance	Consumer/Industrial IoT	Industry-recognized compliance mark	Self-assessment + 3rd party audit
UL Cybersecurity Assurance Program (UL CAP)	Product security testing	UL certification mark	Vulnerability testing + assessment
ioXt Alliance Certification	Smart home, mobile, network infrastructure	Consumer trust, retail requirement	Lab testing + ongoing monitoring
CSA (Connectivity Standards Alliance) Certification	Matter protocol devices	Interoperability + security	Authorized Test Labs (ATLs)
Common Criteria (CC)	High-assurance products	Government procurement	Extensive evaluation (EAL 1-7)

1394.6.2 IoT-Specific Testing Areas

1. Hardware: JTAG, UART, SPI interface exploitation, side-channel attacks
2. Firmware: Firmware extraction, reverse engineering, backdoor detection
3. Network: Protocol fuzzing, man-in-the-middle, replay attacks
4. API: Authentication bypass, injection attacks, authorization flaws
5. Mobile App: Reverse engineering, credential storage, API abuse
6. Cloud: Cloud misconfigurations, data exposure, access control

1394.6.3 Testing Tools

• Firmware Analysis: Binwalk, Firmware Analysis Toolkit (FAT), EMBA
• Hardware: Bus Pirate, Shikra, ChipWhisperer (side-channel)
• Network: Wireshark, tcpdump, Burp Suite, Metasploit
• Fuzzing: AFL, Boofuzz, Peach Fuzzer
• Static Analysis: Coverity, Checkmarx, Fortify

TipSecurity Compliance Resources

1394.6.4 Standards and Frameworks

• NIST IoT Cybersecurity: NIST IR 8259
• ETSI EN 303 645: Consumer IoT Security
• IEC 62443: Industrial Automation Security
• FDA Cybersecurity: Medical Device Guidance

1394.6.5 Certification Bodies

• UL Solutions: Cybersecurity Assurance Program
• ioXt Alliance: Smart Device Certification
• IoT Security Foundation: Compliance Framework

1394.6.6 Vulnerability Databases

• NIST NVD: National Vulnerability Database
• ICS-CERT: Industrial Control Systems Advisories
• CVE: Common Vulnerabilities and Exposures

1394.7 What’s Next

Now that you understand security compliance frameworks, continue to:

• Practice Exercises - Apply your knowledge with hands-on security exercises
• Interactive Security Tools - Use risk calculators and attack surface visualizers
• Worked Examples - Study detailed threat modeling case studies