No More Excuses—Why Device Security Compliance is the Key to Your Product’s Future

Today is going to be all about regulations and compliance in the embedded/IoT/Device security space!

I’ve been working on some really great projects with Device manufacturers and one thing that’s common and most important for all of these projects is compliance.

Device Security: IoT Security Standards You Need to Know

Let’s be real—if you’re building IoT or embedded systems or learning more about device security and still treating security as an afterthought, you’re setting yourself up for some tough conversations down the road. Whether you’re dealing with cars, smart home devices, or healthcare tech, the **regulations are here, and they aren’t going away**. IoT Compliance is no longer optional; it’s mandatory.

But hey, I get it—keeping up with all the standards and acronyms can feel like chasing your own tail. That’s why I’ve pulled together the key device security standards you need to know right now, depending on your industry. These aren’t just suggestions; they’re what will help you grow in this industry, even if you are just starting out. If you are a manufacturer, these will act as a GTM and sales enabler for you when you decide to sell in a particular region. If you are a compliance or security professional these will equip you with understanding the challenges faced by manufacturers as well as what to prioritise from security perspective.

Who Am I to be preaching about IoT/Device security compliance?

I have been part of a few standards organisations’ cybersecurity working groups and my suggestions have been incorporated in some of the important standards and guidelines. Some of them that I remember are:

1. IS0/IEC 27400 - IoT security and privacy - Guidelines

2. ISO/IEC 27402 - IoT security and privacy - Device baseline requirements

3. TEC 31328:2023 - Security by Design for IoT Device Manufacturers - TEC, Dept. of Telecom

4. TEC 31318:2021 - Code of Practice for Securing Consumer Internet of Things (IoT) - TEC, Dept. of Telecom

I’m proud to be part of these working groups (ISO, BIS, TEC etc.) shaping the future of device security! And I encourage you to join this journey and contribute your knowledge and expertise to create stronger cybersecurity standards in your field. Together, we can take charge and drive meaningful change, rather than relying on policymakers who may not fully understand the intricacies of this critical area. Let’s make a real difference!

Before we get started. Here’s a song for you - “Excuses” by AP Dhillon. Don’t worry if you don’t understand Punjabi, enjoy the music and just remember Excuses will take you nowhere. Take a small step today towards device security compliance :)

Alright “No More Excuses” let’s dive in.

ISO/SAE 21434 (Automotive Cybersecurity)

For those in the automotive industry, ISO/SAE 21434 is the globally recognised cybersecurity standard specifically developed for road vehicles, addressing cybersecurity risk throughout the entire vehicle lifecycle. This standard is not simply about patching vulnerabilities as they arise but requires a systematic, proactive integration of cybersecurity from concept to vehicle decommissioning.

It establishes a baseline for a comprehensive cybersecurity management system within the automotive sector, fostering a culture of continuous improvement, proactive risk management, and cross-industry collaboration. If you as an Automotive manufacturer are not implementing these requirements, competitors who are will have a significant advantage in securing consumer trust and regulatory compliance.

ISO/SAE 21434 covers multiple phases and stakeholders, specifying detailed processes across:

1. Risk Assessment and Mitigation: The standard emphasises assessing cybersecurity risks early, identifying potential attack paths, and defining mitigation measures through structured threat analysis and risk assessment (TARA). This process helps quantify risk levels and prioritise mitigation based on potential impact and likelihood.

2. Product Development: Security by Design is a central tenet here. ISO/SAE 21434 mandates the implementation of cybersecurity controls during both hardware and software design phases. This includes things like secure coding practices, encryption mechanisms, secure boot, and integrity verification to protect against unauthorized access and tampering.

3. Production and Operation: Once in production, vehicles must be equipped with monitoring capabilities to detect potential cybersecurity incidents. These capabilities often include logging, anomaly detection, and over-the-air (OTA) updates for secure patch management, ensuring rapid response to emerging threats.

4. Incident Response and Information Sharing: The standard outlines protocols for cybersecurity incident management and emphasizes the importance of information sharing between manufacturers, suppliers, and external entities. It calls for a clear, defined process for incident response, investigation, and communication with stakeholders.

5. Governance and Responsibility: It specifies roles and responsibilities across the supply chain, ensuring that suppliers and OEMs maintain a collaborative and transparent cybersecurity management process. Documentation and auditability are key requirements, which help verify compliance and strengthen accountability.

Overview of the Standard document

ISA/IEC 62443 (OT/ICS Cybersecurity)

If you’re working with Industrial Control Systems (ICS) or Operational Technology (OT), the ISA/IEC 62443 series of standards is critical for achieving and maintaining cybersecurity. Developed to address the unique security challenges in industrial environments, this set of standards provides a structured approach to mitigating cyber risks associated with critical infrastructure—where even a minor breach can result in significant operational and safety consequences.

ISA/IEC 62443 is structured into four key sections that cover different facets of ICS cybersecurity:

1. General (62443-1): This section defines key terms, concepts, and models, providing the foundational framework for understanding and implementing cybersecurity across all areas of ICS.

2. Policies and Procedures (62443-2): The 62443-2 standards outline organisational requirements, such as security policies, risk management, and personnel training. These guidelines help ensure that security practices are standardised and consistently applied at the organisational level.

3. System Requirements (62443-3): This part specifies technical requirements for secure ICS architecture. It covers everything from system partitioning to segmenting networks, managing access control, and implementing intrusion detection to protect against internal and external threats.

4. Component Requirements (62443-4): The final section focuses on the security requirements for individual ICS components, including embedded devices, controllers, and other critical assets. This standard enforces secure-by-design principles, such as secure firmware, tamper detection, and communication encryption.

ISA/IEC 62443 emphasises a “Defense in Depth” approach, mandating layered protections that address threats at each level—from individual devices to network architecture to organisational policies. The series encourages collaboration among OEMs, integrators, and operators to build resilient, adaptable security frameworks, reinforcing that ICS cybersecurity is an ongoing process.

For those managing systems that control critical infrastructure, ISA/IEC 62443 is not just a best practice but a necessity. Compliance not only strengthens security but also demonstrates due diligence to stakeholders and regulators, crucial for trust and operational continuity.

For manufacturers it becomes equally important to make sure their products adhere to the standard as this has become a stringent requirement from critical infrastructure owners and maintainers.

Overview of the standard’s sections

ISO/IEC 27402 (Baseline cybersecurity requirements for devices)

ISO/IEC 27402 sets a global baseline for IoT security and privacy, focusing on embedding security from the ground up rather than as an afterthought. Designed to protect both device and user data, this standard addresses the unique challenges of IoT environments, where a breach in one device can quickly cascade across networks and impact privacy and safety on a large scale.

This standard provides specific guidance across multiple areas of IoT security:

1. Device Identity and Authentication: ISO/IEC 27402 requires that each IoT device has a unique, verifiable identity and robust authentication measures to prevent unauthorised access. This is particularly critical in preventing malicious devices from entering the network.

2. Data Encryption and Privacy: Ensuring data integrity and privacy in transit and at rest is a core requirement. The standard mandates encryption for both, addressing risks like eavesdropping, data tampering, and unauthorized data access.

3. Secure Communication Protocols: IoT devices must use secure, standardized communication protocols (e.g., TLS/SSL) to protect data exchange between devices, users, and networks. This helps reduce the risk of man-in-the-middle attacks and ensures data confidentiality.

4. Update Mechanisms and Patch Management: Regular firmware updates and patching are essential to keep devices secure against newly discovered vulnerabilities. ISO/IEC 27402 outlines best practices for secure, verifiable, and user-transparent update mechanisms to prevent tampering during the update process.

5. End-of-Life (EOL) Security: As IoT devices reach end-of-life, ISO/IEC 27402 requires manufacturers to provide clear guidelines for device disposal and data erasure, helping prevent data leakage from obsolete devices.

6. User Data Privacy and Consent: For IoT devices that collect personal data, the standard specifies measures for informed user consent, clear privacy settings, and secure data storage to uphold privacy and user rights.

ISO/IEC 27402 serves as a foundational benchmark for secure IoT deployments, helping organisations build trustworthy and resilient IoT ecosystems. Ensuring compliance means that security is built into each layer of the device lifecycle, reducing the risk of vulnerabilities and safeguarding user trust.

EN 303 645 (Consumer IoT Security)

In the consumer IoT sector, EN 303 645 serves as the cybersecurity baseline for devices like smart cameras, wearables, smart speakers, and home automation systems. Developed by ETSI (European Telecommunications Standards Institute), this standard outlines essential security requirements to protect consumer IoT devices from common threats and vulnerabilities. Compliance with EN 303 645 not only safeguards user privacy and security but also helps maintain brand reputation in an increasingly security-aware market.

EN 303 645 provides specific measures across multiple areas:

1. No Default Passwords: Devices must avoid using universal default passwords and instead require unique, strong passwords for each device. This mitigates the risk of unauthorised access due to weak or predictable credentials.

2. Vulnerability Disclosure Policy: Manufacturers should have a clear and accessible vulnerability disclosure policy, allowing security researchers and users to report vulnerabilities responsibly. This approach encourages transparency and quick response to potential security issues.

3. Secure Software Updates: IoT devices must support secure update mechanisms to ensure that only verified firmware can be installed. This prevents malicious actors from tampering with updates and helps maintain device security over its lifecycle.

4. Data Protection and Privacy: EN 303 645 emphasizes the importance of data minimization, requiring that only necessary data be collected, processed, and stored. Privacy-enhancing features, such as user-controlled data settings, are recommended to uphold user consent and privacy.

5. Communication Security: Secure communication protocols (e.g., TLS or DTLS) are required to prevent eavesdropping and data interception during device communication with servers, other devices, or apps. This is critical in ensuring data integrity and confidentiality.

6. Minimal Device Exposure: Devices should minimize network exposure by disabling unnecessary services and ports. Limiting access points helps reduce the attack surface and protects against network-based attacks.

7. Account and Credential Security: For devices that require user accounts, EN 303 645 mandates secure credential storage and encourages the use of multi-factor authentication (MFA) where feasible to strengthen access control.

EN 303 645 has become a widely accepted baseline, setting the groundwork for IoT security standards worldwide. Its principles are shaping IoT security laws, certifications, and labelling schemes across different regions and industries. Several international and regional standards reference, have influenced and/or align with EN 303 645 as a benchmark for consumer IoT security. Here are a few prominent ones:

1. UK Code of Practice for Consumer IoT Security: This code was one of the earliest security frameworks for consumer IoT, published by the UK’s Department for Digital, Culture, Media & Sport (DCMS). Many of its principles influenced EN 303 645, and recent updates to UK legislation require IoT manufacturers to follow guidelines in line with EN 303 645.

2. IoTSF Security Compliance Framework: The IoT Security Foundation (IoTSF) offers a compliance framework designed to guide IoT manufacturers on security best practices, with many recommendations aligned to or directly referencing EN 303 645.

3. Australian Code of Practice: Securing the Internet of Things for Consumers: Australia’s government developed this code of practice for consumer IoT devices, heavily referencing EN 303 645’s principles and guidelines to encourage strong security practices for manufacturers and developers.

4. Singapore’s Cybersecurity Labelling Scheme (CLS): Singapore’s CLS provides a labelling system for consumer IoT devices, where devices are rated based on security measures. The scheme is largely based on EN 303 645 and the UK Code of Practice, focusing on requirements such as no default passwords, vulnerability disclosure, and secure updates.

Food and Drug Administration (FDA) Cybersecurity Requirements (Medical Device Cybersecurity in USA)

If you/your company plans to sell medical devices in the U.S., the FDA's cybersecurity requirements are crucial for ensuring device safety and patient protection. The FDA's guidance emphasises a “Total Product Lifecycle” approach, which means that cybersecurity must be embedded in the design, production, and post-market phases of each device. Unlike general IoT devices, medical devices directly impact patient health, making cybersecurity an essential component of patient safety.

The FDA’s cybersecurity guidance covers several key areas:

1. Threat Modelling and Risk Management: Manufacturers are required to perform risk analysis using threat modelling and implement controls proportionate to identified risks. This includes assessing potential vulnerabilities and attack vectors, especially for devices connected to networks or other systems.

2. Security by Design: Security controls must be built into the device from the outset. The FDA mandates the use of secure coding practices, encrypted data storage and transmission, secure boot processes, and tamper-resistant hardware features to ensure that medical devices resist unauthorised access and manipulation.

3. Cybersecurity Labelling and Transparency: Medical devices should include user-friendly cybersecurity labelling. The FDA encourages providing healthcare providers and patients with detailed information on how to configure security settings, apply patches, and report incidents.

4. Secure Update Mechanisms: Devices must include mechanisms for secure firmware updates to address new vulnerabilities throughout their lifecycle. The FDA requires strong version control, authentication, and validation for all software updates to prevent unauthorised modifications.

5. Post-Market Surveillance and Incident Response: After deployment, manufacturers are responsible for continuous monitoring and risk management. The FDA requires a structured incident response plan, which includes vulnerability detection, logging, reporting, and, where applicable, updating devices remotely with patches or mitigations.

6. Vulnerability Disclosure Program: The FDA encourages manufacturers to maintain a vulnerability disclosure program, enabling security researchers and stakeholders to report issues directly. This proactive approach is intended to facilitate early detection and resolution of cybersecurity threats.

By following the FDA’s cybersecurity guidelines, manufacturers are not only allowed to sell in the US market but can better protect patient health, reduce the risk of unauthorised access, and improve the resilience of their devices against emerging threats. Compliance with these requirements not only enhances device safety but also builds trust with healthcare providers and patients, strengthening overall cybersecurity in healthcare.

HIPAA (Health Insurance Portability and Accountability Act) (Medical Data security and privacy)

In the U.S. healthcare sector, if your IoT devices handle patient data, HIPAA compliance is paramount. HIPAA sets strict requirements for safeguarding Protected Health Information (PHI) and mandates that healthcare IoT devices ensure data privacy, confidentiality, and integrity.

Key aspects for device manufacturers include:

1. Data Encryption: All PHI must be encrypted both in transit and at rest to prevent unauthorised access.

2. Access Controls: Devices must incorporate strong user authentication and authorisation controls, ensuring only authorised personnel access patient data.

3. Audit Logs and Monitoring: Devices must log access and changes to PHI, enabling detection of unauthorised access and activity.

4. Data Minimisation and Secure Disposal: Only collect essential data, and ensure secure data deletion methods for decommissioned devices.

UNECE R155 & R156 (Automotive Cybersecurity in EU)

For automotive manufacturers targeting the European market, UNECE R155 and R156 are mandatory standards focused on vehicle cybersecurity and software updates. Compliance with these regulations is essential to obtain type approval for connected vehicles in Europe, where regulatory enforcement is quickly ramping up.

1. UNECE R155 – Cybersecurity Management System (CSMS): R155 mandates that automakers implement a Cybersecurity Management System to manage and mitigate cybersecurity risks throughout the vehicle lifecycle. This includes:

   • Risk Assessment: Manufacturers must conduct detailed threat analysis and risk assessments (TARA) for each system component, identifying potential vulnerabilities across the vehicle's network.

   • Incident Detection and Response: Vehicles must include systems to detect, respond to, and recover from cybersecurity incidents.

   • Supply Chain Security: R155 extends beyond the OEM, requiring cybersecurity protocols across suppliers and third-party vendors.

   • Continuous Monitoring and Patching: OEMs must maintain cybersecurity protections post-market, addressing emerging threats with timely patches and updates.

2. UNECE R156 – Software Update Management System (SUMS): R156 focuses on secure software update management, critical for modern connected vehicles, ensuring that updates are handled securely and effectively. Key requirements include:

   • Over-the-Air (OTA) Update Security: Software updates, including OTA, must use encryption and authentication to prevent unauthorised modifications.

   • Update Integrity Verification: Vehicles must verify update authenticity and integrity before installation, ensuring they aren’t compromised or corrupted.

   • Documentation and Transparency: OEMs must maintain thorough documentation of each software version and update process, providing regulatory transparency.

Both R155 and R156 are integral to connected vehicle security in the EU market, creating a structured, proactive approach to managing cybersecurity risks and secure software updates. Starting early with these standards is crucial, as failure to comply can prevent market entry, disrupt production, and delay sales in Europe.

Cybersecurity Labelling Scheme (CLS) (Device Cybersecurity in Singapore)

Singapore’s Cybersecurity Labelling Scheme (CLS) provides a four-tier rating for consumer IoT devices to indicate their level of cybersecurity robustness, helping both manufacturers and consumers make informed choices.

CLS Levels:

1. Level 1 – Basic Security Requirements:

   • Minimum requirements include:

     • No hardcoded or default passwords.

     • Unique password setup upon initial device configuration.

   • Based on guidelines from ETSI EN 303 645 to ensure basic security hygiene.

2. Level 2 – Enhanced Software Protection:

   • Devices must support:

     • Secure firmware update mechanisms.

     • Encrypted communication protocols to protect data in transit.

   • Builds on Level 1 with additional protections for data security and update integrity.

3. Level 3 – Product Assessment and Vulnerability Testing:

   • Devices are subject to binary code analysis for vulnerability detection in firmware.

   • Independent security testing by accredited third-party labs to validate protection against known threats.

4. Level 4 – Advanced Security Testing:

   • Penetration testing is required to evaluate the device’s resilience against sophisticated, real-world cyber threats.

   • Represents the highest level of assurance by requiring rigorous testing against potential attack vectors, confirming robust security measures.

Mutual Recognition of Cybersecurity Labels

To streamline global cybersecurity standards for IoT, Singapore has established mutual recognition agreements with Finland and Germany, allowing consumer products to be certified across these regions with a single process.

• Finland: In 2021, Singapore and Finland signed an MoU for mutual recognition of cybersecurity labels. Consumer IoT products with Finland's Cybersecurity Label meet Level 3 of Singapore's CLS, and products with CLS Level 3 or above are recognized by Finland.

• Germany: In 2022, Singapore and Germany signed an MRA for mutual recognition of cybersecurity labels. Products with Germany's IT Security Label meet Level 2 of Singapore's CLS, and products with CLS Level 2 or above are accepted by Germany.

Cyber Trust Mark (Consumer Device Cybersecurity in USA)

The U.S. Cyber Trust Mark is an emerging cybersecurity labelling program for smart devices, aimed at enhancing consumer confidence by clearly indicating the security level of products. This mark will be issued by the Federal Communications Commission (FCC), in collaboration with the National Institute of Standards and Technology (NIST). This mark will help manufacturers demonstrate their commitment to securing devices against cyber threats, offering transparency in an era of increasing security risks.

General Data Protection Regulation (GDPR) (data privacy for EU Customers)

We all know GDPR is the gold standard for data privacy in Europe. If your devices are collecting or processing personal data in the EU, this regulation has to be front and center in your development process.

Why This Matters?

Look, compliance isn’t just about avoiding fines or getting your products to market—it’s about protecting your users and your reputation. If your product gets hacked, the fallout is far worse than the cost of integrating security up front. Trust me, the regulations are here for a reason, and the stakes have never been higher.

What Should You Do?

Step one: figure out which standards apply to your industry and region. Then, start baking them into your process now. Don’t wait until you’re up against a deadline. And if you’re feeling overwhelmed, let’s chat. I’m here to help you navigate the maze of regulations and make sure your products are both secure and compliant.

Credits:

1. Rajnikanth cop pic - https://pbs.twimg.com/media/EXlLkPjXgAI4xKc.jpg

2. ISO/SAE 21434 document overview - https://www.iso.org/obp/graphics/std/iso_std_iso-sae_21434_ed-1_v1_en/fig_1.png

3. ISA/IEC 62443 standard sections - https://gca.isa.org/hs-fs/hubfs/21-29%20-%20ISAGCA/ISAGCA%20Blog%20Images/ISA-IEC-62443-Standards.png?width=2458&name=ISA-IEC-62443-Standards.png

4. CLS levels diagram - https://www.csa.gov.sg/our-programmes/certification-and-labelling-schemes/cybersecurity-labelling-scheme