Arthur's Legal

Security and Privacy in IoT



Technology changes the world at a fast and massive scale. Digital technology makes innovation possible in our society and economy. Cloud computing, data analytics and Internet of Things (IoT) will expedite this pace by hyper-connecting people, organizations and data with billions of objects. In such diverse physical-cyber, cyber respectively cyber-physical ecosystems, it remains to be seen how demand side, supply side, policy makers, law enforcement, authorities as well as end-users and other stakeholders are going to understand, build, deploy and use IoT ecosystems and its related products, systems and services.


A. JOIN ARTHUR'S LEGAL's 2018 PRIVACY IN IoT WEBINARS, SUPPORTED BY AIOTI (Alliance for Internet of Things Innovation)


Under the leadership of Arthur's Legal, AIOTI and its WG3 Privacy in IoT Taskforce will organize seven (7) open webinars in 2018, also available to non-members of AIOTI, with the focus on the GDPR and related topics. This is a unique opportunity to learn and discuss (A) where the GDPR may be a pain to implement in legacy systems and how to address those issues, (B) where the GDPR is an enabler for your organisation, community, customers and ecosystems, and (C) how to get to Privacy by Default, Privacy by Design and Resilience by Design. 


Please subscribe to our newsletter, in which we will keep you up to date with dates, login details and the latest news on the GDPR, Privacy in IoT and related topics.


Webinar 1: GDPR: Processing, Protection, Security & Strategies

Wednesday 28 March 2018, from 10.00 - 11.00 CET


Webinar 2: X-by-Design: Upstream & Downstream Resilience

Wednesday 4 April 2018, from 10.00 - 11.00 CET


Webinar 3: State of the Art Privacy Principles & Requirements

Wednesday 25 April 2018, from 10.00 - 11.00 CET


Webinar 4: Consent Management & Engagement in IoT

Wednesday 2 May 2018, from 10.00 - 11.00 CET


Webinar 5: Compliance, Accountability, Assurance & Penalties

Wednesday 9 May 2018, from 10.00 - 11.00 CET


Webinar 6: IoT Ecosystems, Pre-Procurement & Collaboration

Wednesday 16 May 2018, from 10.00 - 11.00 CET


Webinar 7: Data Subject Rights & Data Management in IoT

Wednesday 23 May 2018, from 10.00 - 11.00 CET


Please subscribe to the Privacy in IoT Mailing List.

We will keep you updated on the Webinar Login Details, and the latest developments on Privacy in IoT:




Combating the vast domain of cybersecurity, security and safety, with the even vaster domain of IoT is a necessity, yet quite complex and difficult to grasp and comprehend. In order to come to workable and actionable frameworks and models to address the pre-requisite trust components of Security and Privacy in IoT, come to the mandatory level of appropriate accountability (as for instance set forth the GDPR) and enable organisations in any sector, including public and private, to assess which technical and organisational security measures it needs to consider and implement, various organisations have set up committees, taskforces and workshops. In 2016 and first part of 2017, this has resulted in about 30 papers that describe such recommendations, frameworks and other guidelines on state of the art Security in IoT.


The IoT Unit of the European Commission, together with relevant stakeholders including AIOTI and key IoT industrial, demand side and policy players have recently organised two workshops, namely AIOTI Workshop on Security & Privacy in IoT in June 2016 and the European Commission’s Workshop on Security and Privacy in IoT in January 2017. These have resulted in recommendations, principles and requirements as set forth in its respective reports in order to enable and facilitate the increase of security, privacy, identify minimum baseline principles and requirements for any IoT product, service or system, and therewith trust in human-centric IoT. These can be structured and analysed in the perspective of the following layers and dimensions, where dimensions may be relevant in one, more or all layers:



  1. Service
  2. Software/Application
  3. Hardware
  4. Infrastructure/Network


  1. User/Human Factor
  2. Data
  3. Authentication

The reports based on the conclusions from the two workshops result in a structured set of about 50 principles and requirements, and also make visible where appropriate maturity of those principles have been reached, and where possible gaps and points of attention can be identified and how to address those.


State-of-the-Art Security in IoT Principles & Requirements





  • Basic principles:
    • Human-centric approach: Security and privacy should be universally applied to all users.
    • Privacy by design: Privacy of users must be embedded into the design of business processes, technologies, operations and information architectures. Each service or business process designed to use personal data must take all the necessary security requirements into consideration at the initial stages of their developments.
    • Privacy by default: The strictest privacy settings and mechanisms must automatically apply once a user acquires a new product or service; no manual change to the privacy settings should be required on the part of the user.
    • Decoupling multiple identities: It should be easy to decouple multiple personae of the users from one another.
    • Identity protection by design: Decoupling personal identity of a user from device identity should be possible.
  • User’s awareness and control:
    • Transparency of data processing: The service provider should empower the users to know what the devices are doing and what personal data they are sharing and why, even if it concerns M2M communications and transactions.
    • Transparency of privacy policy: The service provider should ensure that the user is and remains clear and aware of privacy issues, choices it makes and possible consequences thereof.
    • Transparent roles: The service provider should ensure clear allocation and identification of roles, including who is data controller, co-controller, processor, co-processor, and so forth.
  • Handling of personal data:
    • Non-discriminatory practices: The service provider should ensure non‑discriminatory practices against users and businesses on the basis of information derived from IoT deployments (e.g. within smart cities).
    • Manufacturer-implemented parametrization: The user should be able to manage rights for accessing data controlled by them based on the assessment where and when a Thing or IoT ecosystems in its lifecycle comes into contact with personal data, creates/derives (new) personal data, or otherwise processes personal data, while keeping in my mind the contextuality of purposes and use, as well as multi-purpose Things and IoT ecosystems.
    • Accountability: Any service provider should be accountable for regulatory, contractual and ethical compliance.
  • Data segmentation and classification: “Data” implies “data of any form, nature or structure, including without limitation proprietary and non-proprietary data, confidential and non-confidential data, non-personal and personal data, as well as other human readable or machine readable data.”[1] Service providers should ensure segmentation and classification of data, that is contextualising data with respect to its purpose, risk and impact, and persona. Data classification enables processing of data with respect to the description of different classes of data. For instance, regarding personal data, data should be segmented according to the multiple personae each user has, and the related protection – including fundamental and consumer rights – it has.
  • Indication of purpose: The service provider should indicate the purpose of data collection and ensure that personal data is collected for that specified, explicit and legitimate purpose and not further processed in a way incompatible with those purposes.
  • Consent: Based on the particulars provided by the service provider to the user, the user should express an informed and unambiguous consent per contextual processing of personal data (which data for which use). No data should be collected and processed without this consent.
  • Data minimisation: The less data an actor can access, the less risk there is of a security breach. If data is minimised based on a specific purpose, there is less chance that the actor will breach trust (and the law). Data minimisation starts with only requesting, collecting, obtaining, deriving and processing personal data to the extent necessary (need-to- know principle). The data provider should observe the principle of data minimisation, i.e. (i) only collect personal data whose collection the user has consented to, and (ii) erase personal data from whenever they are stored as soon as they are no longer necessary.
  • De-identification: The data controller should design and apply and de identification capabilities so personal data is de identified as soon as legally possible.
  • Data control: User should have the possibility to opt-out, right to their data, portability of their data, communication platform to control data access and to ensure security and privacy, and the overall securing of personal data processed, also in the context of related systems and devices.
  • Data access: The service provider should make it possible to technically regulate access to data to define who can use it for what purpose, and how that can be made transparent, and subsequently measured and monitored (relevant in e.g. connected automobiles domain).
  • Data ownership: The service provider should clarify the principles of ownership of user’s data.
  • Data management/Data stewardship: The service provider should apply a process to manage data of users.
  • Data isolation: Functional separation of datasets and databases should be in place.
  • Security of personal data: The service provider should obey by the principles of data availability, integrity, confidentiality, transparency, unlinkability/isolation and intervenability.
  • Encryption:
    • Encryption by default: Encryption should be applied at all stages of handling data, including in communication, storage od data at rest, storage of keys, identification, access, as well as for secure boot process.
    • Encryption at the application layer: Data should be encrypted on the application layer. End-to-End security, cryptographic principles and key management are extremely important and should be carefully described.
    • Standardisation: All aspects of cryptographic principles and key management should be carefully described.
  • Compliance with data protection legislation: Any service provider should be accountable for regulatory, contractual and ethical compliance.
  • Accountability: Any service provider should be accountable for regulatory, contractual and ethical compliance, as well as for any misuse of collected personal data. If data is compromised, disclosed, accessed or lost, clear statement by vendors, data controllers and data processors on impact is another prerequisite.
  • Risk impact assessment by design: The service provider should carry out an assessment of the risk of data being compromised, disclosed, accessed or lost. Likewise, an assessment of the consequences from regulatory, contractual and ethical perspective should be carried out.


  • Metrics: The service provider should engage dynamic trust key performance indicators and metrics on security, privacy, safety, resilience, reliability and the like.
  • Life time protection: Give security, safety and privacy protection over the full life time.
  • Single point of contact: The service provider should provide a single point of contact for personal data protection and privacy.
  • Support: End of support: Where the current practice is about 12 to 15 years, the end of life cycle and the related support is prerequisite. Questions to be addressed are: what happens if a services agreement is lawfully terminated, is there an update possibility, when will updating and upgrading become limited, and who is accountable for the risk of not updating IoT devices and systems.
  • Security by default: The service provider should ensure that the most secure, proven, well understood and securely updateable setting are indispensable before starting operations and during IoT life time.
  • Updatability:
    • Secure updates: Trusted and transparent updates should only be provided by authorised parties, not by malicious actors.
    • Frequency of updates: Software providers should ensure regular updates and upgrades during the device lifetime.
  • Accountability and liability: Manufacturers must be accountable and liable as they have or should have total control of the entire design, manufacturing and software development lifecycle; to execute third-party software the manufacturer should set the rules to ensure that the software is compliant with them.
  • Third-party libraries: Software developers should put rules in place for maintaining, updates and checking for vulnerabilities of third-party libraries.
  • Information exchange: Stakeholders should be active in sharing information about incidents/potential vulnerabilities with each other.
  • Security principles:
    • High-level baseline: High level baseline should be applied when safety is at stake or critical infrastructure or national safety can be materially impacted.
    • Safe and secure interactions: Manufacturers have to implement and validate safety principles, separately from security principles.
    • Security rationale: Manufacturers should be required to provide explanation of implemented security measures related to expected security risks from any designer of IoT device, auditable by independent third party.
    • Security evaluation: Manufacturers should specify precisely capabilities of device of a particular type. This could help to manage liability and evolutivity on system level.
    • Security levels: The industry should make use of the security scale 0 – 4 fit to the market understanding.
    • Sustainability: Manufacturers should ensure that connected devices as well as any IoT component as defined above are durable and maintained as per its purpose, context and respective life cycle.
    • ‘As-if’ by design: The devices and ecosystems must be engineered as if these will (now or in a later phase) process personal data.
    • Assurance: Component and system suppliers need to be prepared for security monitoring and system maintenance over the entire life cycle and need to provide end of life guarantees for vulnerabilities notifications, updates, patches and support.
  • Certification and Labelling:
    • Certification: Device manufacturers should test devices and make use of existing, proven certifications recognized as state-of-the-art based on assessed risk level. Additional introduction of a classification system to certify devices for use in particular use case scenarios depending on the level of risk should be encouraged.
    • Trusted IoT label: Labels such as the ‘Energy efficiency label’ of appliances should give a baseline requirement of protection based on the level of assurances and robustness, and should be used to classify individual IoT devices.
  • Secure Performance and Functionality:
    • Defined functions: Manufacturers should ensure that IoT devices are only able to perform documented functions, particular for the device/service.
    • Secure interface points: Manufacturers should identify and secure interface points also to reduce the risk of security breach.


  • Authentication of identities among themselves: In the context of communication of various applications, authentication of identities should be open to all technologies and applications.


  • Architecture & Ecosystem:
    • Interoperability: Stakeholders should aim at achieving interoperability of components and communication protocols.
  • Knowledge sharing:
    • Monitor and respond: Stakeholders should ensure continuous monitoring and improvement of relevant IoT ecosystems, including clear metrics and measurements.
    • Information sharing platforms: Stakeholders should be active in sharing information about incidents/potential vulnerabilities with each other.


  • Independent privacy and security audits: Organizations of certain size and public bodies should mandatorily carry out third party privacy and security audits.
  • Harmonised industry approach: Stakeholders should participate in standardisation efforts of the functional and security assurance requirements through common harmonised industry approach. This should ensure that devices are designed, manufactured and assembled with clear understanding of what means what, and to what extent there is consensus in the related complex value chain and ecosystems. At the same time, the goals of data protection such as limiting the scope of data processing to the necessary level should be promoted, as well as data segmentation, mapping, categorisation, purpose limitation, data isolation, and data control and data access of personal data are seen as prerequisite elements.
  • Reduce impact of national regulations: Stakeholders should actively participate  in harmonisation efforts to reduce the impact of different national regulations.
  • Taxonomy: The basic taxonomy does not need to be perfect, but sufficiently workable. Definitions established as prerequisite include data, personal data, data controllers and other actors, the personal data life cycle, IoT ecosystems and the physical and virtual “Things”.


[1] Cloud SLAs Standardisation Guidelines