1362  IoT Security Frameworks and Standards

1362.1 Learning Objectives

By the end of this chapter, you should be able to:

  • Recognize common IoT security frameworks (NIST, OWASP, ETSI)
  • Understand OWASP IoT Top 10 vulnerabilities
  • Select appropriate standards for specific IoT use cases
  • Apply industry security certification requirements
  • Navigate compliance landscapes (GDPR, CCPA, PSTI)

1362.2 Standards and Certification Reference

Understanding relevant standards helps you build compliant, secure IoT systems and accelerates certification processes.

1362.2.1 Security Standards for IoT

Standard Organization Scope Key Requirements Certification Body Year
IEC 62443 IEC Industrial IoT & Control Systems Defense in depth, zones, security levels 1-4 IEC, ISA 2007-2018
NIST 8259 NIST Consumer IoT Devices Baseline security capabilities, secure updates NIST 2020
ETSI EN 303 645 ETSI Consumer IoT No default passwords, secure boot, data protection ETSI 2020
ISO/IEC 27001 ISO Information Security Management ISMS framework, risk management ISO 2013
UL 2900 UL Software Cybersecurity Vulnerability testing, penetration testing Underwriters Labs 2017
FIPS 140-2/3 NIST Cryptographic Modules Hardware/software crypto validation NIST 2001/2019
Common Criteria ISO 15408 IT Security Evaluation Assurance Levels (EAL1-7) Multiple 1999

1362.2.2 Privacy and Data Protection Standards

Standard Region Scope Key Requirements Enforcement
GDPR EU Personal Data Consent, right to erasure, data minimization €20M or 4% revenue
CCPA California Consumer Privacy Opt-out, data access rights $7,500 per violation
UK GDPR UK Personal Data Similar to EU GDPR post-Brexit £17.5M or 4% revenue
PIPEDA Canada Personal Info Consent, purpose limitation CAD $100,000
LGPD Brazil Personal Data Data protection principles 2% revenue up to R$50M

1362.2.3 IoT-Specific Certifications

Certification Organization Focus Validity Cost Range
ioXt Alliance Industry Consortium Smart home, mobile, network security Ongoing compliance $5K-25K
Matter CSA (Connectivity Standards Alliance) Smart home interoperability + security Product lifecycle $7K-50K
PSA Certified Arm IoT device security (Level 1-3) 3 years $10K-100K
CTIA Cybersecurity CTIA Mobile/cellular IoT devices Annual $15K-40K

1362.2.4 Wireless Communication Standards

Standard Technology Frequency Security Features Use Case
IEEE 802.11i Wi-Fi Security (WPA2/WPA3) 2.4/5/6 GHz AES encryption, 4-way handshake Wi-Fi IoT devices
Bluetooth SIG Bluetooth/BLE 5.x 2.4 GHz AES-128 CCM, LE Secure Connections Wearables, sensors
IEEE 802.15.4 Zigbee, Thread, 6LoWPAN 2.4 GHz AES-128 encryption Home automation
LoRaWAN 1.0.4 LPWAN Sub-GHz ISM AES-128 encryption, session keys Long-range sensors

1362.2.5 Compliance Requirements by Region

Region Safety Privacy Radio/Wireless Environment Product Security
EU CE Mark GDPR RED (Radio Equipment Directive) RoHS, WEEE Cyber Resilience Act (2024+)
US FCC CCPA (CA), state laws FCC Part 15 EPA IoT Cybersecurity Act (federal)
UK UKCA UK GDPR UK Radio Equipment Regulations UK WEEE PSTI Bill (2024)
China CCC PIPL SRRC (Radio) China RoHS MLPS 2.0
Australia RCM Privacy Act ACMA WEEE ACSC guidelines

1362.2.6 Industry-Specific Standards

Industry Standard Focus Key Requirements
Healthcare HIPAA (US), MDR (EU) Medical device security, patient data Encryption, audit logs, access controls
Automotive ISO/SAE 21434, UN R155 Vehicle cybersecurity Threat analysis, security updates, incident response
Industrial IEC 62443, NERC CIP Critical infrastructure Network segmentation, access control, monitoring
Financial PCI DSS, SOC 2 Payment systems Encryption, secure transmission, compliance audits
Smart Home Matter, ioXt Consumer devices Secure pairing, local control, privacy

1362.2.7 Security Testing Standards

Standard Type Description Typical Duration
OWASP IoT Top 10 Vulnerability Framework Common IoT security weaknesses Ongoing reference
OWASP ASVS Application Security Verification requirements L1-L3 2-8 weeks testing
NIST SP 800-53 Security Controls Federal information systems 3-12 months
ISO 27002 Security Controls Information security guidelines 6-18 months
GSMA IoT Security Mobile IoT Cellular device security 4-12 weeks

1362.2.8 Quick Decision Guide: Which Standards Apply to Your Product?

TipStandards Selection Framework

Step 1: Identify Device Category - Consumer IoT (smart home) → ETSI EN 303 645, Matter, ioXt - Industrial IoT (factory) → IEC 62443, ISO 27001 - Medical IoT (healthcare) → HIPAA, MDR, IEC 62304 - Automotive IoT (connected car) → ISO/SAE 21434, UN R155 - Critical Infrastructure → NERC CIP, IEC 62443

Step 2: Determine Target Markets - EU → CE Mark, GDPR, RED, Cyber Resilience Act (2024+) - US → FCC, CCPA, IoT Cybersecurity Act - China → CCC, SRRC, PIPL, MLPS 2.0 - Global → ISO 27001, UL 2900, Common Criteria

Step 3: Choose Wireless Technology - Wi-Fi → IEEE 802.11i (WPA3) - Bluetooth → Bluetooth SIG Security - Cellular → GSMA IoT Security - LPWAN → LoRaWAN Security

Step 4: Privacy Requirements - Personal data collected? → GDPR, CCPA, PIPEDA - Children’s data? → COPPA (US), Age-Appropriate Design Code (UK) - Health data? → HIPAA (US), MDR (EU)

1362.2.9 References and Resources

1362.3 IoT Security Frameworks and Standards

⏱️ ~10 min | ⭐⭐ Intermediate | 📋 P11.C01.U06

1362.3.1 OWASP IoT Top 10 (2018)

Rank Vulnerability Example
I1 Weak, Guessable Passwords Default admin/admin
I2 Insecure Network Services Open Telnet port 23
I3 Insecure Ecosystem Interfaces Unprotected REST API
I4 Lack of Secure Update Mechanism No firmware signature verification
I5 Use of Insecure Components OpenSSL Heartbleed
I6 Insufficient Privacy Protection Excessive data collection
I7 Insecure Data Transfer/Storage Unencrypted Wi-Fi, plaintext DB
I8 Lack of Device Management Can’t remotely disable compromised device
I9 Insecure Default Settings All features enabled by default
I10 Lack of Physical Hardening Exposed JTAG debug port
TipAddressing OWASP IoT Top 10

Quick fixes: 1. I1: Enforce strong password policy, no defaults 2. I2: Disable unnecessary services, use firewalls 3. I3: Implement API authentication (OAuth 2.0, JWT) 4. I4: Sign firmware with digital signatures 5. I5: Keep libraries updated, use dependency scanners 6. I6: Minimize data collection, anonymize PII 7. I7: Use TLS/DTLS, encrypt storage 8. I8: Implement remote management, kill switches 9. I9: Secure by default, require opt-in for features 10. I10: Disable debug ports, tamper-evident seals

1362.3.2 NIST Cybersecurity Framework

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '14px'}}}%%
graph LR
    NIST[NIST Cybersecurity<br/>Framework]

    NIST --> ID[Identify<br/>Asset Management<br/>Risk Assessment]
    NIST --> PR[Protect<br/>Access Control<br/>Data Security]
    NIST --> DE[Detect<br/>Anomalies<br/>Continuous Monitoring]
    NIST --> RS[Respond<br/>Incident Response<br/>Analysis]
    NIST --> RC[Recover<br/>Recovery Planning<br/>Lessons Learned]

    ID --> PR
    PR --> DE
    DE --> RS
    RS --> RC
    RC -.Continuous Improvement.-> ID

    style NIST fill:#2C3E50,stroke:#16A085,color:#fff,stroke-width:3px
    style ID fill:#16A085,stroke:#2C3E50,color:#fff
    style PR fill:#16A085,stroke:#2C3E50,color:#fff
    style DE fill:#E67E22,stroke:#2C3E50,color:#fff
    style RS fill:#E67E22,stroke:#2C3E50,color:#fff
    style RC fill:#16A085,stroke:#2C3E50,color:#fff

Figure 1362.1: NIST Cybersecurity Framework: Five Functions with Continuous Improvement Loop

1362.3.3 IoT Security Standards

Standard Organization Focus
ETSI EN 303 645 ETSI (Europe) Consumer IoT security baseline
IEC 62443 IEC Industrial automation security
ISO/IEC 27001 ISO Information security management
UL 2900 Underwriters Labs Software cybersecurity testing
ioXt Alliance Industry consortium IoT security certification
Matter CSA Smart home security & interoperability

1362.3.4 Regulatory Requirements

Region Regulation Scope
EU GDPR Data privacy, right to erasure
USA IoT Cybersecurity Improvement Act Federal device procurement
California SB-327 Reasonable security features
UK PSTI Bill Default password ban
China MLPS 2.0 Multi-level protection scheme

Question 5: A medical IoT device manufacturer claims “military-grade AES-256 encryption” but transmits data over HTTP without TLS. What OWASP IoT Top 10 vulnerability does this represent?

💡 Explanation: This is I7 (Insecure Data Transfer and Storage)—data transmitted without transport-layer security. The manufacturer’s claim about AES-256 is likely referring to data-at-rest encryption, but data-in-transit over HTTP is vulnerable to man-in-the-middle attacks. Even if application-layer encryption is used, HTTP lacks certificate validation, allowing MITM attackers to intercept traffic. Medical devices require both encryption at rest AND TLS/DTLS for data in transit.

1362.4 Security-by-Design Principles

⏱️ ~12 min | ⭐⭐⭐ Advanced | 📋 P11.C01.U07

WarningCommon Misconception: “We’ll Add Security After the Prototype Works”

The Misconception: Many IoT developers believe security can be “bolted on” after functionality is proven, treating it as a final polish step like UI refinement.

The Reality with Real Numbers: - Mirai Botnet (2016): Compromised 300,000+ devices that shipped with default passwords “admin/admin” - a trivial 5-minute fix during development that manufacturers skipped - Jeep Cherokee Recall (2015): $1.4 billion recall cost plus reputational damage because security wasn’t architected into the entertainment system from day one - the cellular modem had direct CAN bus access with no authentication - Verkada Cameras (2021): 150,000 cameras (hospitals, prisons, schools) breached because super admin credentials were stored in plaintext support systems - would cost $0 to hash passwords during initial database design

By the Numbers: - Retrofit cost multiplier: Adding security after deployment costs 10-100× more than building it in from start (IBM System Sciences Institute) - Average IoT breach cost: $4.24 million per incident (Ponemon 2021), with 206 days average time to identify breach - Mirai attack window: Devices compromised in <5 minutes after connecting to internet with default credentials - Patch deployment rate: Only 28% of IoT devices receive security patches within 90 days of vulnerability disclosure (Forescout 2022)

Why It Fails: 1. Architectural constraints: Retrofitting encryption requires CPU/memory headroom that wasn’t planned - example: cheap sensors with 32KB RAM can’t add TLS later 2. Backward compatibility: Deployed devices can’t change authentication schemes without breaking existing systems 3. Update mechanisms: You can’t add OTA updates if devices weren’t designed with secure boot and code signing 4. Cost explosion: Field technician visits for 8.5 million smart meters = $85-170 million (vs. $25.5 million to build security in)

The Right Approach: Treat security like power requirements or network connectivity - a non-negotiable architectural decision from requirements phase, not an optional feature.

1362.4.1 Principle of Least Privilege

Concept: Grant only minimum necessary permissions

// BAD: Device has admin access to entire system
// GOOD: Device can only write to its own data endpoint

// Example: Scope-limited API token
// Token allows: POST /devices/device123/data
// Token denies: POST /devices/device456/data (different device)

1362.4.2 Defense in Depth

Concept: Multiple layers of security controls

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '13px'}}}%%
graph TB
    ATT[Attacker]

    ATT -->|Layer 1| L1[Physical Security<br/>Tamper Detection<br/>Secure Enclosure]
    L1 -->|Layer 2| L2[Device Security<br/>Secure Boot<br/>Encrypted Storage]
    L2 -->|Layer 3| L3[Network Security<br/>Firewall<br/>VPN/TLS]
    L3 -->|Layer 4| L4[Application Security<br/>Authentication<br/>Authorization]
    L4 -->|Layer 5| L5[Data Security<br/>Encryption at Rest<br/>Access Logging]
    L5 -->|Layer 6| L6[Monitoring & Response<br/>IDS/IPS<br/>Incident Response]

    L6 --> ASSET[🎯 Protected Asset]

    style ATT fill:#e74c3c,stroke:#c0392b,color:#fff
    style L1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style L2 fill:#E67E22,stroke:#2C3E50,color:#fff
    style L3 fill:#16A085,stroke:#2C3E50,color:#fff
    style L4 fill:#16A085,stroke:#2C3E50,color:#fff
    style L5 fill:#2C3E50,stroke:#16A085,color:#fff
    style L6 fill:#2C3E50,stroke:#16A085,color:#fff
    style ASSET fill:#27ae60,stroke:#16A085,color:#fff,stroke-width:3px

Figure 1362.2: Defense-in-Depth: Six Security Layers from Physical to Monitoring

1362.4.3 Secure by Default

Concept: Devices ship with secure settings

Examples: - ✅ No default passwords (force change on first use) - ✅ HTTPS/TLS enabled by default - ✅ Unnecessary services disabled - ✅ Automatic security updates enabled

// Example: Force password change on first boot
void setup() {
  if (isFirstBoot()) {
    Serial.println("SETUP REQUIRED");
    Serial.println("Create new admin password (min 12 chars):");

    String newPassword = waitForUserInput();
    if (newPassword.length() < 12) {
      Serial.println("ERROR: Password too short");
      ESP.restart();  // Force retry
    }

    saveEncryptedPassword(newPassword);
  }
}
TipMinimum Viable Understanding: Secure Defaults

Core Concept: Secure defaults means devices ship in their most secure configuration out of the box, requiring users to explicitly enable risky features rather than disable insecure ones. Why It Matters: The Mirai botnet infected 300,000+ devices because manufacturers shipped them with default passwords like “admin/admin”; users rarely change defaults, so insecure defaults become permanent vulnerabilities at scale. Key Takeaway: Design IoT devices to require password creation on first boot, disable unused network services by default, enable encryption by default, and require explicit user action to enable debugging interfaces or remote access features.

1362.4.4 Fail Securely

Concept: Failures should not compromise security

// BAD: Door unlocks if error
if (checkAuthorization() == ERROR) {
    unlockDoor();  // INSECURE!
}

// GOOD: Door stays locked if error
if (checkAuthorization() == AUTHORIZED) {
    unlockDoor();
} else {
    logFailure();
    alarmTrigger();
}

1362.4.5 Privacy by Design

Concept: Build privacy into system from the start

Principles: - Minimize data collection (only collect what’s necessary) - Anonymize personal data - User control and transparency - Secure data deletion

# Example: Anonymize location data
def anonymize_location(lat, lon, precision=2):
    """Reduce GPS precision to protect privacy"""
    # Instead of: 37.7749295, -122.4194155 (exact)
    # Return: 37.77, -122.42 (city-level)
    return round(lat, precision), round(lon, precision)

# User can choose precision level:
# 0 = country, 1 = state, 2 = city, 4 = neighborhood, 6 = exact

1362.5 Real-World Case Studies: Detailed Analysis

1362.6 What’s Next

Apply security frameworks to real systems:

Recommended next: Security Design Principles →