To start, could you briefly describe your role in CSA and how the Cybersecurity Engineering Centre is structured, especially regarding IoT and consumer device security?
I am part of CSA’s Cyber Security Engineering Centre where we are tasked to engineer secure technology adoption & lead cybersecurity assurance to support CSA’s mission of keeping Singapore’s cyberspace safe and secure. My role in CSA relates to technology evaluation and engineering secure technology adoption where I assess emerging and existing technologies to identify risks and formulates guidance to derisk the adoption of such technologies. I work closely with the Cybersecurity Certification Centre which is the scheme owner of Singapore’s Cybersecurity Labelling Schemes for consumer IoT and medical services. As a product of our work on technology evaluation and cybersecurity certification, we translate the identified risks, requirements and best practices into standards and guidelines. For example, Singapore’s Cybersecurity Labelling Scheme led to our national standard TR 91 and the subsequent international collaboration to develop the cybersecurity labelling framework through the ISO/IEC 27404 project.
For those who may not be familiar, could you explain what Singapore’s Cybersecurity Labelling Scheme (CLS) and the national standard TR 91 are, and how they relate to or build upon ETSI EN 303 645?
The Cybersecurity Labelling Scheme (CLS) is a voluntary scheme for consumer IoT and is the first of its kind in the Asia Pacific region. As a multi-level labelling scheme, it enables consumers to identify products with better cybersecurity provisions and make informed decisions.
To develop the CLS, principles and concepts were derived from relevant standards and guidance documents. We referenced the EN 303 645, which provided baseline controls to mitigate common cybersecurity risks in consumer IoT. Singapore referenced these controls and distributed them across different levels of the CLS that incorporate both self-declaration and third-party testing requirements. The multi-level labelling structure allows manufacturers to enter at an appropriate level while providing a clear pathway for security enhancement.
After we launched the CLS scheme, we worked with industry partners and academia to publish the national standard TR 91 on cybersecurity labelling for consumer IoT to crystallise the design principles and concepts of the CLS labels to provide guidance to developers and test laboratories on the provisions that underpin the labelling of consumer IoT devices.
Singapore is often cited as a pioneer in IoT security labelling. Could you walk us through Singapore’s philosophy in balancing regulation, incentives, and voluntary adoption in elevating IoT security? How does CSA balance supporting innovation and market entry, especially for smaller manufacturers, while ensuring that the baseline security remains meaningful?
The CLS scheme is flexible to cater for a wide range of manufacturers and devices so as not to stifle innovation. The Cybersecurity Labelling Scheme (CLS) has four levels, with the first two levels based on self- declaration by manufacturers and the higher levels requiring security testing and security assessment performed by approved independent testing labs.
At CLS level one, devices must meet the baseline security requirements, such as having no universal default passwords, developer’s commitment to providing software updates, and having vulnerability disclosure policy in place. For the more mature manufacturers, they may apply for higher CLS levels from the onset. The multi-level labelling structure allows manufacturers to enter at an appropriate level that corresponds to their cybersecurity maturity level.
The CLS is a voluntary scheme, with the exception of home gateways where Singapore’s telecommunication regulator, the Infocomm Media Development Authority (IMDA), mandated for home gateways sold in Singapore to be labelled under the CLS. Regulatory measures are imposed on home gateways as they are critical entry points to home networks, exposing connected devices to cybersecurity risks.
How do you address technical constraints in IoT devices (for example, secure update mechanisms or cryptographic requirements) when the hardware is very resource-limited?
The CLS was designed deliberately to allow constrained IoT devices to be included. At CLS level 1, the scheme only requires essential security practices — no universal default passwords, a defined update process, and a vulnerability reporting channel. As manufacturers move up the label levels, additional measures such as ETSI EN 303 645 controls, secure development practices, binary analysis and penetration testing are added progressively.
The scheme also allows security functions to be supported at the gateway or system level. For example, devices can offload TLS, key handling or update integrity checking to a gateway or hub as long as the device does not undermine trust.
Certification and testing can vary between labs and countries, and many devices integrate third-party components or open-source libraries. How does CSA ensure consistency in evaluations and maintain accountability when recognising results from international partners or certifying devices with these components?
For Singapore’s CLS, CSA has developed an assessment methodology that specifies how each security provision is to be evaluated and provides minimum criteria for the security provisions to be met.
CSA has also placed requirements for test laboratories to be ISO 17025 accredited and for their evaluators to have the relevant cybersecurity competencies.
At the higher levels of the CLS, there are additional requirements for devices using third-party components or open-source software, manufacturers needs to design and develop the device using a secure engineering approach, use components from a secure supply chain with no known unmitigated vulnerabilities and maintain an inventory of components including its version, applied patches and updates. For mutual recognition to be possible, the requirements of schemes have to be aligned , which means we get similar results regardless of the scheme that the product has applied for.
From your perspective, how have EN 303 645 and Singapore’s TR 91 contributed to raising baseline IoT security, and what indicators or metrics do you use to assess whether these efforts are actually improving consumer trust or reducing vulnerabilities in the market?
EN 303 645 provides an excellent foundation that establishes essential cybersecurity provisions for consumer IoT devices. Scheme owners can build upon EN 303 645 to specify their cybersecurity requirements relevant to the degree of assurance that they want to achieve.
Singapore measures the impact of the CLS from an ecosystem perspective. From the manufacturers’ support and buy in angle, we look at the number of labelled products in the market (manufacturers’ support and buy-in). But beyond that, we also monitor the security posture of labelled products as a whole and see if there is a trend of products moving from lower levels to higher levels. From the consumer angle, we are interested in their awareness of the CLS and whether they know the importance of purchasing labelled products. We track their awareness in CSA’s annual cybersecurity awareness surveys. From the threat landscape perspective, we also monitor the number of infected devices. It was reported in 2024, there were about 2700 infected devices identified in Singapore after CSA took part in a cyber operation against a global botnet. We hope to see the number of infected devices going down over time as more labelled products are used.
Looking ahead, which classes of emerging IoT devices (such as smart health, edge sensors, or autonomous systems) pose the toughest challenges that current standards may not yet cover?
CSA is concerned about connected medical devices, especially as we see the use of such devices gaining momentum to improve patients’ health and lower care costs. However, connection of devices to networks or the Internet also exposes devices to increased cyber risks. The impact of healthcare breaches worldwide is among the highest among all sectors.
Taking into consideration the cybersecurity threats on increased connectivity and digitalisation of medical devices, the Cybersecurity Labelling Scheme for Medical Devices [CLS(MD)] was formed as a joint initiative by CSA and healthcare regulators. Similar to the CLS for consumer IoT, the CLS(MD) is a multi-level labelling scheme to improve the cyber hygiene of connected medical devices and better secure Singapore’s cyberspace for both data protection and patient safety in our healthcare sector.
How do you see global efforts evolving to reduce fragmentation between ETSI, NIST, ISO and various national schemes? What role can Singapore play in driving that convergence?
As more nations develop their own labelling scheme and standard, the global landscape of IoT cybersecurity regulations and standards is diverse and fragmented. While there have been mutual recognition arrangements established among some labelling schemes, such arrangements are only short-term solutions, and it is unsustainable to proliferate such arrangements. This is why Singapore has been working with international partners on ISO/IEC 27404, which is a based on multilateral approach to align their labelling schemes under. The ISO/IEC 27404 provides a cybersecurity labelling framework that covers the core elements of labelling schemes, the labelling process and how requirements are compatible with one another.
Singapore has also been facilitating a multilateral approach through our Singapore International Cyber Week (SICW). The SICW provides an excellent platform for discussions on scheme harmonisation and cross-recognition opportunities. These multilateral engagements allow us to identify common implementation challenges and work together on solutions that benefit the entire ecosystem.
In your talk you mention galvanizing a global IoT effort — how do you see roles for smaller nations or developing economies in adopting or adapting frameworks like CLS?
We encourage such nations and economies to adopt common frameworks such as the ISO/IEC 27404 and EN 303 645 to align and harmonise scheme requirements. As we are working towards interoperable cybersecurity requirements among schemes, we are agnostic towards any specific international, regional or national standard as a basis for technical requirements. Standards and guidance documents are deemed relevant as long as they are aligned with common categories of requirements determined through the multi-lateral approach.
We can also encourage partners to participate in multi-lateral fora where jurisdictions identify common requirements to harmonise as the threat landscape evolves.
Finally, what advice would you give to countries or regulators that are just beginning to design IoT security labelling or certification frameworks?
For countries just starting to develop IoT security labelling or certification schemes, I would first recommend beginning with established multi-lateral approaches like ISO/IEC 27404 and EN 303 645 as the technical baseline rather than creating entirely new approaches from scratch. These approaches provide well-tested security provisions that address common IoT vulnerabilities whilst ensuring your scheme can interoperate with others.
Countries can also consider participating in international harmonisation fora to understand other nations’ policy perspectives and learn from their experiences in implementing their schemes. Before designing labelling schemes, countries are recommended to engage their ecosystems comprising of manufacturers, testing laboratories, and consumers early. Understanding their needs and constraints will help countries design practical schemes that achieve good adoption rates and delivers meaningful outcomes that align with their national objectives.
Then, depending on the country’s policy considerations and ecosystem needs, labelling schemes can be designed with flexibility in mind. For instance, Singapore chose a multi-level approach to allow manufacturers to enter at appropriate levels while providing clear pathways for improvement. This supports both innovation and provides security baselines that corresponds to manufacturers’ maturity and capabilities.
