2pm: Side room. Thursday, 29th October to 26. IoT.
YEVHENIYA NOSYK: Good afternoon and welcome to the IoT working group, well, I am not a chair of but me and Anna Wilson will be replacing Anna Maria and Ramona today, a couple of announcements, the voting for the PC election closes at five today. The dinner starts at 7.30, it's a short walk from the hotel. And please rate the talks.
So as always we'll start with some housekeeping and then we have three talks today. Your chairs ‑‑ so Ramona was selected during the last meeting, we welcome her to this working group and Anna Maria couldn't make it to the meeting for a very good reason.
Housekeeping. So for the minutes of RIPE 92, so the minutes are already online and unless there are any objectionses to them, the chairs will approve the minutes.
Code of Conduct, RIPE meetings are safe place, we want to ensure that everybody feels welcome here so please follow the Code of Conduct, which means please respect each other.
If you are participating in person, if you want to ask a question at the mic, please state your name and affiliation; otherwise, if you are participating remotely, you can still ask a question, just ensure you share the slide deck if you want us to read the question in the room.
Our first speaker is Muhammad, he will talk about internet scale classification of IoT and non‑IoT devices from a single packet. You have 30 minutes.
MUHAMMAD SANGEEN: Thank you so much for the introduction. And good afternoon everyone, my name is Muhammad Sangeen and I am a PhD candidate at the university of Twente. Today I will talk about classifying IoT and non‑IoT on internet scale and then apply and how we applied the technique on a large scale in a network Telescope and this work is done in collaboration with CAIDA at UCSD San Diego. So let's start.
So why do we care about classifying what type of devices is sending, what type of devices can scanning the internet. Today one of the example is for example asewer rue taken in 2025, the volume was almost 30 terabits better second, same Cloudfare reported in April 2026 that they mitigated a lot of traffic, almost 6.5 trillion. Same Microsoft reporting in November 2025 that he received almost 30 terabits of DDos attack per second and that attack was coming from more than 500,000 IP addresses and it is equal to more than 50 million ‑‑ streaming more than 1.5 next movies and Norway reported since June, they were attacked by DDos attack and disrupted their government services.
So the question is before every attack that happened, all the networks asking by different type of devices all day and if we have actionability, if we have intelligence, for example, what type of devices is scanning the internet, we can prevent somehow those kind of attacks.
And why device type matters. Today the platform that we have available are mostly tell us, for example, what the the IP address, from which country, which type of network that is coming and what time and what port addresses the attacker is using, it rarely tells us the devices it's coming from. For example, if we see a camera or TV box in a network we are only server expected or if we have mobile application API, if we see a packet or scanning coming from a camera or TV box itself is a sign of it's a warning sign.
So in this presentation, we are working on three questions, the first question is how distinguishable with IoT and non‑IoT devices from the network traffic, how well we can, how well can unseen IoT and non‑IoT devices be identified for example the IoT devices which we have never seen in a network traffic. The third question is how much do IoT and non‑IoT contribute to global internet scanning compared with non‑IoT devices.
So part 1 of this presentation is fingerprinting a device from one packet.
So how can we identify a device. The first challenge is how can we identify a device so we have two types of technique available, first one is active and the second one is passive. In active approach we basically send packets to the device and based on the response, we decide if this is an IoT device or this is a non‑IoT device. And the problem with the active approach is if a device is scanning the internet from behind a firewall, we cannot send them a packet and this matter is intrusive and time consuming.
The second method is analysing traffic passively, we classify if this is an IoT device or non‑IoT device, this method also has some problems for example we need rich header feature and the problem with this is if we saw a packet coming from raw socket, we cannot classify that device. So what we did, we decided to go with passive approaches. There are two types, the first one is which need flow which we can say they are flow based approaches and they need by directional traffic and the second one is packet header approaches.
The problem with the flow‑based approaches, which needs bi‑directional traffic, it cannot be used an an environment such as Telescope which mostly receive one‑way traffic and they don't respond to any other traffic. And the second approach which is a packet header approach, we don't need to respond to the device and it is suitable for all type of vantage point, including network Telescope.
So we decided to go with that the packet header based approaches. So there are two problem with packet header based approaches. To classify something using a passive approach, we need signature, in case of IoT and non‑IoT devices we have almost 7,000 signature from public repository called Zardaxt and it's frequently updated. In the case of IoT devices we have less or almost 750 signatures from Satori, but those two were last updated more than a decade ago and they rarely had new IoT signature.
So what we did to solve this problem, we built our own IoT we fingerprinted an AS‑Set from six test bed, i will explain later how we did. The second problem with passive approaches is if packet or traffic is coming from IPs which are using raw socket, we cannot classify those traffic because the traffic shows the tool, not the device and there is the approach to solve this problem, we use an approach from a recent paper from 2022, they have a criteria for classifying if an IP is sending raw socket or not, so we use that approach to filter out all the sources or IP addresses which were sending raw socket packets.
So how we generated our own fingerprinted AS‑Set, so we took, we took a dataset from six testbeds including Alto, Georgia Tech and my own UT and all the testbed has 224 devices and unique 190 model using all these six approaches, we generated 216 fingerprints, why we had 216 and not 224, because all the testbed were independent and there were some, for example, Amazon Echo IoT device, it existed in all the testbed devices so what we did the devices which were shared in all the dataset or all the testbed or those devices and we end up with 21 unique IoT fingerprints.
For Zardaxt non‑IoT data sets, they have fingerprints from six families including Android, windows, IOS and Mac OS, for non‑IoT dataset, we used Zardaxt repository. From a syn packet, how we created a fingerprint, there are two types of header field in any type of packet, first is connection dependent field and the second is connected independent field for example IP address, auth number, sequence and checksum number, we cannot use that to create a fingerprint, they are connection depend tent and every connection it changes, so we use the connection independent field for example, window size, MSS or TT L, those are connect independent.
So we have, we got fingerprints for both IoT device and non‑IoT devices, the next step for us is to do we, if this methods works or not, the first approach we use was model three approach and we used greedy forward selection to compare both IoT and non‑IoT device signature and see how different they are from each other.
So using a greedy forward selection, almost 91% of IoT signature are different from non‑IoT device signatures. For example, there are 10% of the signature of IoT devices or 10% of the IoT devices which are using non‑IoT device signature for example Samsung TV is one of the IoT devices in our dataset which uses Android so they were almost 10% of the devices which were using non‑IoT device signatures.
The second step we did, we trained five different machine learning model on the IoT and non‑IoT dataset and we found out that the best model in our scenario was random forest because the false positive red or a... we decided to go with a non‑forest model.
So the approach for relation we use was called... we got all the IoT and non‑IoT device signature and hide one device and trained on the other devices and then label the unseen devices but in short they could see that we got the random forest was almost 92% and false positive rate were .14%, in simple words, out of 100 unseen devices that we are classifying, 92% of the time, the model would be correct. Or out of a thousand phone and PC devices, only 2 or 1 would be called IoT devices. So it means the model accuracy and fast false positive rate is pretty good.
The third part of the presentation is then we applied our approach on CAIDA or Telescope which covers the /8 network space and we labelled around 6 million devices.
In short what a network Telescope, this is unused IP address space and the network Telescope we used were almost 12 million unused IP addresses, it was a really large Telescope and any traffic that a network Telescope is unsolicited because there's no service offer anything running in a network Telescope. So our data was of 30 days and we collected data from 16th May til the 14th June 2026 we collected almost 3.2 million packets and 10.8 million unique IP addresses send us the traffic and then after the raw socket packet using next paper approach, we classified ‑‑ we label 6.92 million IP addresses, we label how much of those IP coming are from an IoT device. And how much percentage of data is from coming from an non‑IoT device.
So this was our approach. I will explain it in very briefly so we collect traffic and we filter out to only TCP syn packets which were almost 90% of the traffic and then we extract all the relevant field that we need to create a fingerprint. Then we created a fingerprint and then we removed all the irregular sources in using this spoki approach and the devices whichwere sending multiple fingerprints.
So after removing all the sources which were sending us traffic using a potential raw socket, we end up with almost 6.92 million packets and then we labelled the 6.52 million packets, so we use an approach, the first approach were exact packet look at for example as we have the data of IoT and non‑IoT device, if we found a match in the exact look up, we don't do anything. If we cannot found a match for the packet in exact look up, we use or classifier to label that packet and yeah these were the approaches we used. This way we labelled almost 7 million IP addresses.
Out of the 6.92 million packets, 2.6 we labelled with false positive rate of almost.15%, 2.6% IoT, 91.2% were non‑IoT and 2.6% were the devices which have signature or signature with both IoT and non‑IoT devices and 3.4% of the devices our model could not label.
Based on our result, IoT devices, so they were almost 44,000 IoT devices which were scanning the network and 431,000 IoT devices which were scanning the network and per scanner means per scanner how many syn packet those IP send us, sent to the Telescope and out of all the scanning traffic volume, how much percentage of the volume were sent by IoT devices. And to classify if an IP scanning or not, we use the Zeek default, we use for example in a scanner is sending traffic to more than 25 addresses and it is scanning more than 115 ports, then only we considered a scanning if it's, in five minute window, if it is scanning really slow or not scanning, unique 25 addresses we don't label it as a scanner so we use a very conservative values to classify if something is scanned or not.
And then we draw all the device type on a... chart and as we can see in case of non‑IoT scanner, the top 1% of non‑IoT scanner is sending all 66% of the traffic, but in case of IoT devices, the scanning is more widespread.
So, this was the devices which we found out, this was the top ten devices we found out with sending us traffic, the first one was Smart TV and ring based and all that so why the Smart TV and Roku are red, when we investigated, then the mart TV and row queue are both using Android based operating system, which I will explain later why that is important for us.
And the problem IPs we found are Android is more than 200,000 and then we check, first of all 44% of the scanners we found were Android based scanners an there's a report from an X lab, they found OK, how many Android scanners, what's the percentage of Android scanner and from which country the Android scanners are coming. So we use maximum data to see from which country the scanning is coming. If you can see on the country, Brazil, India and South Africa and X lab report you can see that the scanner that we found and from which countries we are originated are the same as reported by X lab, they gave us a bit of confidence, OK, our results are,s results that we estimated are somehow effect.
Other report also found the same type result for example, FBI warn in June 2025 there may ‑‑ there may be devices infected and Google found Android botnet are scanning or are, Android defences are infected a lot in the wild now, authenticity similar to our research and these are the reports from December 2025 by X lab report which are saying that the countries that they found, the from where the Android devices were most infected were almost similar to us so again this kind of explains why our estimated research might be correct and then we used the max mandate that you see OK, we have found the IoT scanners are coming, from the non‑IoT scanners are coming but we could not find any visible pattern in that so the internet is, the scanning is really widespread and it's coming from all the world and then we analyse how and what they scan, saying all the device, all type of devices are using peer like pattern, the Telnet ports and they were not visible which we could distinguish between if IoTs are scanning different than non‑IoT devices.
So what this matters for operators for example is this matter can be can be used to generate attack intelligence, if there is a sudden wave of scanning and we use our matter to label the device, we label the device saying OK most devices are IoT so this can mean OK possibility a botnet which we can report, network hygiene for example we have an API or a server, we are expecting only Android application to reach to or download or upload some data and if you are seeing traffic from an IoT devices, this can be a sign or this is really unexpected and same it can be used to infect, to inform in fact potentially infected customer.
This method we applied on a Telescope but it can be applied at the CGNat, IXP and cloud network, if we drop the syn packets first, we can use the label to prioritise which type of network we need to analyse.
And the key takeaway is one packet is enough.
We tested it on real devices and the false positives were less than 1% and the... were almost 92%. IoT scan about three times more than its share. And also it can be a new signal for operators.
Yeah, thank you, thank you so much.
(APPLAUSE.)
YEVHENIYA NOSYK: Thank you. Do we have any questions? Do we have anything on Meetecho? In this case, thank you very much.
(APPLAUSE.)
I would like to introduce your next speaker, Martine Sophie Lenders, who will talk about DNS piracy. You have 30 minutes also.
MARTINE SOPHIE LENDERS: Hello, as I was so nicely introduced by name is Martine and I'd like to talk about how to enhance privacy of constrained IoT devices in DNS and to that end also talk a little bit about a protocol I developed named DNS over CoAp.
So first I I will give an introduction, why do we need another DNS over XYZ, what the heck is CoAp and also yeah, why are we doing this.
And then get directly into the threat model we analysed and describe the method and valuation set up and then go to our results and in the end, conclude my talk.
So first what is our motivation.
So first we have a typical attack scenario an eavesdropper wants to surveil name resolution in the IoT to find out the product name and then from the product name, find some vulnerability and try to control it, to do, for example, a botnet with it.
And the common counter measure for that is encrypt the name resolution triggered by IoT device and you can then forge a response or something like that.
So the challenge, however, is that we are not working with Smart TVs or fridges or voice assistants or the raspberry pi is not a device that we are targeting, we are targeting basically micro controllers, ESP32s, we have only a few kilobytes of RAM and at best a few megabytes of persistent storage, but most of the time we are working in the kilobyte range.
The other challenge is that we are using constrained IoT networks, it's wireless communication, it's not wi‑fi, it's BLE, Zigbee, Lora and they are characterised by low throughput, high packet loss, asymmetric link characteristics, we have a high penalty when we are sending out large packets which means there is some fragmentation, either on the link layer itself happening or just above the link layer between the network and layer and the link layer and that is because we have very small frame sizes, typically something between 50 to two hundred kilobytes per second and we actually want to avoid this fragmentation because the high penalty is we have slow data rates, you see on the slide 1 to 200 kilobits per second, so if we can avoid it, we try to avoid it.
So if you look at possible solutions for encrypted DNS, we have, we are all familiar with DNS over HTTPS, you might have heard of DNS over DTLS and they all in one way or another conflict with our resource constraints. TCP and TLS over UDP are well known that they don't work that well with their congestion control over these kind of constraint networks. DNS over detail has no segmentation mechanism so it entirely conflicts with our link layer PDUs so we have brought a new proposal forward that is DNS over CoAp which is standardises at RFC 9953, it comes with encrypted communication, CoAP already so far as the data gram transport layer, there it is again, and also object security which is basically an application based encryption of your objects you can directly send over CoAP and it has a segmentation mechanism called block wise transfer which splits the message into small equal sized chunks and then also against the higher link layer packet loss, you can mitigate with that en route caching.
So what is CoAP? CoAP, is a constrained application layer protocol which is a way to implement a rest API over UDP, so you can say it as an HDPT for the IoT, though the message format is completely different and as I said it works over UDP so you have to do all the reliability and things like that yourself in the application layer.
And you have as I said it's a rest API, so you have the get, post, put and delete requests and semantics look similar to HTTP. But in CoAP, we have a fetch request which is very similar to Get in that it's there to get some content from the device without changing anything, but in contrast to Get where you have to put all the data you want to deliver somewhere in the query parameters, you can actually put the data you want to deliver in the payload of the request. So you have basically the best of both worlds with get where you have cacheable responses and paused where you can put the data foot payload.
Then we have again the two CoAP security modes, first of all we have DTLS, it's great when you have control over the transport you are using but if you are for example using intermittent approximate eye, that goes over unencrypted channel, the objects you are sending out is in the open and what we want to do caching with CoAP, we might have proxies on the way so there's also an alternative which is OSCORE, where you basically encrypt the object and it's safe for any intermittent proxy. For the threat model, it's a well known threat modelled used in this research to distinguish DNS traffic from data traffic and that is why, it's a problem that exists also for DNS over HTPS and the typical mitigation to techniques EDNS zero padding and adding artificial delays when you send your requests, however it conflicts with our constrained use case because for EDNS, there is actually a recommendation to pad it to multiple of 128 bytes which conflicts with our small frame sizes and the artificial delays conflict with the high latency we face in the constrained IoT as well as the low data rates so what do we do.
We could actually use the constraint use case to our advantage. Because there are some features that help us here. And to that end, we analysed leaking header fields to identify these possible counter measures and actually goal 2 can be relevant for non‑IoT devices because we also have found some of these leaks in DOH. And to spoil the solution already a little bit, basically what we are doing is ELIDing headers that are very obvious that we can do because we have some header compression from the constraint IoT protocols most of the time, then resize the message, split is that equally surprised strings, those who have paid protection might already know what I am talking about here.
And then everything else, you disguise the remaining header, encrypt them or randomise them.
So what are the advantages that we have for constrained use case. Again for the method sizes for splitting them, we just use the block wise transfer that is available in CoAP. So when we have a big message we just split it up into smaller chunks and then send it to the destination and in that format.
And for ELIDing headers we use static context header compression which is a framework for both header compression and fragmentation, we can basically set some rules where we say if the IPv6 has this value, then you can just leave it out of the packet.
For our method, we first collected some data from the HTTP archive, took the URL from that, got the house name and used public resolver to resolve the AAAA record and HTPS record and used those.data objects to run them to 296 scenarios and used packet traces from that to do some machine learning based analysis on that to find out can they distinguish the DNS traffic and data traffic and how did they do that using feature important mechanisms.
So what are these 296 scenarios. And why do we need 296 scenarios. Again our goal is explore the advantages of the contained use case to limit the distinction and analyse leading header fields and identify possible counter measures and we had a question what is the potential of CoAP block wise transfer, what's the potential of header collision and how do different network set ups and protocols or security modes fair.
And because of that, we have this nice table in our paper which looks a little bit intimidating, I admit, but let's just go through that on the basically on the left we have the formats we are using on the top we have the network scenarios consisting of unconstrained link layer and on the right, chick and the protocols with HTTPS core, OS score and onion OSCORE and different block wise and different network scenarios shall the network scenarios were using direct communication with the server that's both DNS and data server which isn't that realistic but still something that might happen.
Then the same via the proxy we callP1 and then where the more realistic scenario the DNS server and data server are split and there's a sniffer or eavesdropper that is basically looking out for the packets on the wireless domain.
And for the forms we first of all for the data used JSON and CBOR, took out JSON objects and converted them to CBOR and used them instead for the data. But we also used different DNS message from it, once the DNS message format you have in DOH but we also developed because even those messages can get quite large for our constrained use case, we have a basically compressed DNS message format which is based on CBOR and for that even though it's not that of much a turning of the stalk, if you want to read it, we are very happy if we can receive any feedback on that.
And I can also give a completely different talk all about this topic, if you want. And in addition to normal OSCORE, we use something called onion CoAP, a way to do onion routing with OSCORE and you have a multi‑shelled OSCORE object. Yeah, and the twos here mean you use encrypted core or CoAPs and we have the three variance used for SCHC which is either SCHC uses rules to describe how packet should be compressed and for the first, we use split rules, which is basically one compression rule per server, minimum results which is one compression rule for both servers, we basically for example compress the addresses down to one bit, there's one bit identified as a server. And we use peer‑based rules where we basically use the device, abstract the device as the peer and it allows us to use one rule for each server. It gives us basically three scenarios in each column here or six when he have onion OSCORE.
So what is the header field analysis we are doing, we wanted to find out which parts of the packet give the DNS away.
And for that we trained binary classifier to distinguish between DNS and data traffic.
And we did that actually bit by bit, we didn't select any specific feature in the packets but put every bit of the packet into the classifier. This is a bit insane to be honest but we had the calculation power so we just did that because since we comparing Ethernet packets and SCHC frames which are completely different beasts, this was basically the only common denominator we had.
Then to find out which of these bits is actually important, we went through every column in our dataset and shuffled them, which is called permutation importance and then looked how the accuracy changed and if this was a big change, then this bit carries actually identifying information.
We then mapped these important bits back to the original header field which gave us the sort of bit map of leaks for all the packages and thus a clear picture which actually reveals what is DNS and what not.
So for our results, this is basically these bit maps I generated. On the X axis you see the bits, I also resolved it to bytes on and the X axis you say the change in accuracy due to the permutation. I think I need water.
So here you see, for example, a spike for the IP address which is already compressed down to a single bit, but it's very important for the distinction here but the IP address in this case gives it away. And you also can see there's a small spike for the unencrypted URL host information in the header. The first leak we identified is actually address port or host limit information in the header. For the second category we found that the alternating nature of DNS and data messages, if you imagine send out a data packet, there's a host name, you send out a DNS request, and that is also because we have all very small cache sizes and very long sleep periods, this is basically every time the case, you send out the data packet and that leads to growing sequence numbers to be able to identify these DNS and data messages.
And even in DOH, this is a problem, especially if you are using HTTP 2 because the TCP sequence number gives it away. The second leak is alternating sequence numbers, message IDs and packet numbers. Something that other researchesers before found message sizes we didn't find that important at least when we just using unchanged data, not using our approaches because this is why we have the solution of resizing the equal message lengths using small block sizes but we didn't put it first, the small block sizes, here's my block wise transfer graphic, something between 16 and 64 bytes, and here you can see on the A axis the scenarios and the Y axis the binary classifier. In yellow you see large block sizes with 1,000 and 24 bytes and small block sizes with 64 bytes and you see that the accuracy goes down when the block size also goes down.
For the second solution to use peer‑based SCHC rules, there you have the SCHC device combined with the device addresses to one common device address and that means that you have two rule ones, one for device one and one for device 2 which you can use for the different server addresses in this example. And that means that you only prepend the rule ID 1 and no other identifying information to the payload.
And here you can see especially if you look at the peer‑based approaches here are marked in red and the comparable scenarios are marked in pink, but again the accuracy goes down and this time also by 10 or 20 points.
So the first solution or the first remedy against this distinction is so ELIDE headers as our recommendation but then where we look at peer‑based rules, then the length suddenly becomes important again because here we see in this where we have the bits on the lower and somewhere far beyond the IPv6 headers and CoAP headers, have this important parts and that's actually our feature of active padding, so that's where the packet ends so the lengths becomes important again.
And so the other thing you need to do to hide your DNS traffic is to ah yeah, block wise transfer, yes, so this is because we have these blackbox stringed up but the last block is always had a little bit smaller than the rest and this week do while padding the last block and luckily there is already a CoAP padding option and basically pad the core to the same length of the rest of the blackbox. And so our second recommendation is to resize.
And the last solution we provide randomise messages if you can or tokens or packet numbers, whatever you want to use. Because here you can see again this bit map on the top you see it without randomised IDs and token is basically what gives it away. And on the bottom it's completely different things that are important but the over accuracy goes down and as you can see in the legend and the feature importance has actually changed.
So the last recommendation we give is to disguise your headers if you can't ELIDE them or resize the packets. In conclusion, DNS over CoAP allows you to encrypt queries for the constrained IoT. But encryption alone does not guarantee you from privacy. The problem is encrypted DNS traffic can still be told apart from regular data traffic and our proposed strategy is to get rid of the obvious, ELIDE headers using peer‑based chick header compression, then equal out the message sizes, split it into small chunks and pad the last chunk and disguise what remains and randomise or incrept what you cannot he will lied, the recommendation is ELIDE, resize and disguise.
And yeah, as a last comment as I said, Docis standardised, RFC 9953 and we welcome feedback on our draft and if you want to go deeper in the research, read our paper we published in this year and we have some artefacts if you want to play around with the data yourself or try reproduce our research. Thank you. Do we have any questions.
YEVHENIYA NOSYK: Thank you very much. (APPLAUSE.)
Any questions? Maybe I will ask a question, so are you aware of any implementations of the standards, already used somewhere in the wild?
MARTINE SOPHIE LENDERS: I have some prototype and there's a request of a student of mine in underbound which is currently poor requested but no, there's a big problem that we don't have that much implementation and every time I ask resolver implementers if they want to implement it the first thing I get is yeah but we want to see first some more deployment in the wild before we integrate a new whole protocol strike into our code base, yeah, if you want to implement this, please help us, we really want to see more of the deployment of that.
YEVHENIYA NOSYK: OK. Anything on Meetecho? OK, thank you very much.
(APPLAUSE.)
Our final talk is going to be remote presented by Anna Maria Mandalari and the talk is Cyber Resilience Act, the implementation update for the RIPE community.
ANNA MARIA MANDALORI: Hello everybody, can you hear me? Sorry, I am not able to be there, I am sorry, for good reason. I hope to see you all in May. You should be able to see the slides.
YEVHENIYA NOSYK: Yes, it's all good.
ANNA MARIA MANDALORI: Thank you. OK, I wanted to take this time just to give you a short update on the Cyber Resilience Act as you may know is considering considerable the internet of things devices on the internet and the time is coming really short, it will be mandatory for IoT manufacturers including routers, even software like from VPN from December 2027. The most immediate change and already some things are already started like, for example, mandatory reporting. So I would like to basically start this conversation here at RIPE 93 and continue the conversation, of course, in the next meeting and in the mailing list. After the meeting we'll start a thread and start discussing and working on this.
So there are three different dates. In July the Commission published guidance covering issues such as scope, notifications and reporting and most of you also working in collaborating with standardisation, you may know there are standard organisations that have named been the European Commission... ETSI and they are already in 17 drafts standards draft reported by ETSI ENISA and three other standards implemented by... in September 2026 there's another important date where reporting duties became in place, and mandatory, this means that any business.... we needed to notify the European Commission through their platform.
And then the most date is 11th December 2027 when all the regulation is coming in place and will become mandatory, there are important updates about the OpenSource.
So just to recrap, the CRA regulates products, supplies on the EU market in the course of commercial activity, even if you are a manufacturer of course, you are selling in Europe, you are, you need to be compliant with the Cyber Resilience Act, it reaches equipment, software on which networks depends, the technical description is implementing regulation 2025 for 23 the 2 that includes routers, modems, intended for internet connection switches. The precise ... and core functionality...depend on the product itself, for a network operator the first question is the role, plug in supply chain. Buying a product does not itself establish the operator is the manufacturer, supply a product under your own name or making as a substantial modification on the product before selling it may change the analysis so complete products and the distribution model, these things from an operator's... and other regulations.
Article 14 covers two, three years; actively exploited vulnerability and severe incidents affecting security, notification requires reliable... existence of vulnerability... but first require an early warning of 24 hours, so I don't know how this is possible to be honest. Followed by a notification within 72 hours of awareness. The final report for exploited vulnerability, the agreement is 14 days after a collective or mitigating measure is available of course. For severe incidents it's one month after the incident notification. How does it work then, notification goes through a single reporting platform, you make available one month ago, and also you need to basically report it to your CSIRT in your country and ENISA. It should be considered alongside customer communication, coordinated with ability handling, etc.
So these operational recommendations greater than separately statutory requirements, a short reporting the line is difficult if... has to work out who can act. You need to sign owner and back up and platform registration process before any incident applies, just a reminder this is already in place so any IoT manufacturers or anyone... they need to do that to keep enough product information to identify effectively in very quickly.
You will also need to establish how you can issue records in time it becomes aware and evidence of exploitation or incident, how do I know how much an incident can be severe, how much is the timeline of reporting that needs to be applied. These are all open questions to be honest the entire community should address I think in open, within the fact that this is already mandatory, no time for organising an organisation in this... there's also something about OpenSource. The Commission distinguished software outside commercial activity and OpenSource software so individual contributions to softer outsider the contributor's responsibility are also different case. A commissioned product can remain subject to manufacturer even when its source code is open. So a steward is a legal person supporting specific OpenSource on a sustained basis and... that regime includes cybersecurity policy and specified reporting duties, this is something to clarify even for OpenSource software, even if you are using OpenSource software in your digital product.
So, as I said before, there are many technical standards that have been developed, in the end, we have 70 standards that are drafted by ... if you are a member of an see or even if you are representing any entity that is interested on responding of drafting of the standards, you can participate with public inquiry that was published some months ago.
And at the moment this comments that were received by the community are now received by the... with the subgroup of the US R working group working on addressing these comments but the open group is still open, as a RIPE community we can, let's say, draft something, reviewing the standards and drafting some comments, this is why I wanted to start this conversation in the mailing list.
So this is suggested conversation, lifecycle approach makes suppliers support commitments more realto planning. So as for support and...A security update is aspirational concept, operators need to understand testing, auditing, deployment, and impact.
So these are proposed discussion priorities for the RIPE community on this. First we need practical examples for network operations that could include standards work and useful example include the support lifetime to match deployment cycles that the requirements... second what we could do as a community is select scope examples, network appliances, software distribution and OpenSource governance, still it's a big question which is the part of the device or the digital element and which part of the software is...... relief coordination problems between manufacturers and customers, any community discussions should follow also these.
So this is my proposal basically for the big 20 that is coming up in 2027, we have limited time before as a community to respond to the standards that have been drafted. So if you have any thoughts, feel free to share it here today, or in any case I will, as I said, start a thread in the mailing list so we can discuss this better. Thank you a lot.
(APPLAUSE.)
YEVHENIYA NOSYK: Thank you very much, do we have any questions or comments? Meetecho? No questions today. Thank you very much
ANNA MARIA MANDALORI: Thank you.
YEVHENIYA NOSYK: That concludes the IoT session. Please don't forget the voting period for the PC election closes at five. The dinner starts at 7.30; it's a short walk from the hotel. Please rate the talks, it's really helpful for the chairs.
Thank you.
(APPLAUSE.)