I just opened the article/blog section on Concergens company web page with my post about information security trends especially related to embedded systems and IoT. More regulation is coming this year and next year. The blog post is available in English and Finnish languages.
Information security requirements are increasing
https://www.convergens.fi/post/information-security-requirements-are-increasing
Tietoturvavaatimukset kasvavat
https://www.convergens.fi/fi/post/tietoturvavaatimukset-kasvavat
Earlier related post
https://www.epanorama.net/newepa/2023/11/14/embedded-systems-and-iot-security-technical-article/
64 Comments
Tomi Engdahl says:
https://etn.fi/index.php/72-ecf/17919-tekoaely-vaatii-vankkaa-turvaa-verkon-reunalla
Tomi Engdahl says:
https://owasp.org/www-project-dependency-check/
Tomi Engdahl says:
Yocto vs Ubuntu Core for the Cyber Resilience Act
https://www.brighttalk.com/webcast/6793/650594?mkt_tok=MDY2LUVPVi0zMzUAAAGcimM2j-Um_9p5Pf8rRCK00BsA9vSKP5Jq2U_ylcuE1ogIgdoDylXLmPLDznChWMzZtcjKDd4QxduA5X7CQZn2TUjxaxrbLajneVsSjqUwcMKMBoI
Tomi Engdahl says:
SDLC, or Software Development Life Cycle, is a process that guides teams through the phases of planning, creating, testing, and maintaining high-quality software. It provides a structured, cost-effective, and time-efficient framework for managing projects to ensure software meets customer expectations and requirements. Key phases typically include planning, analysis, design, development, testing, deployment, and maintenance.
Phases of the SDLC
Planning: Involves defining the project scope, goals, and resources.
Analysis: Gathers and analyzes user requirements to ensure they are clearly understood.
Design: Creates a blueprint for the software, detailing the architecture, user interface, and other technical aspects.
Development: The actual coding and building of the software based on the design specifications.
Testing: Verifies that the software works as intended, identifying and fixing bugs and flaws.
Deployment: Releases the software to the production environment and makes it available to end-users.
Maintenance: Provides ongoing support, updates, and bug fixes for the software after it has been deployed.
Benefits of using SDLC
Improved quality: Ensures software is developed with a focus on meeting requirements and is thoroughly tested.
Better planning: Allows for more accurate estimation of time, cost, and resources.
Increased efficiency: Provides a structured approach that minimizes waste and keeps projects on track.
Risk reduction: Helps mitigate project risks and reduces the costs associated with fixing problems late in the process.
Security and compliance: Integrates security and compliance measures throughout the development process, helping to meet regulatory requirements
Tomi Engdahl says:
https://www.uusiteknologia.fi/2025/11/18/iec-standardi-auttaa-teollisuuden-nis2-vaateita/
Tomi Engdahl says:
Nämä asiat kiristävät ensi vuoden kyberturvaa
https://www.uusiteknologia.fi/2025/11/28/nama-asiat-kiristavat-ensi-vuoden-kyberturvaa/
Tietoturvayhtiö Check Pointin tutkijoiden mukaan vuonna kyberturvallisuutta pahentavat tekoälyagentit, kvanttilaskenta ja identiteettihuijaukset. Samalla toivotaan uusien NIS2:n ja EU:n tekoälyasetusten sekä muun säätelyn parantavan ensi vuoden tilanteita.
Check Point uusimman ennusteraportin mukaan vuodesta 2026 on tulossa tietoturvan murroskohta, jossa uusin tekoäly, kvanttilaskenta ja Web 4.0 -ympäristöt tulevat käyttöön. Varsinkin kun niissä yhdistyvät tekoälyn lisäksi uusimmat pilvipalvelut, verkot ja fyysiset järjestelmät.
Lisäksi kvanttikehitys voi horjuttaa pian perinteisiä salausmenetelmiä ja uudet immersiiviset ympäristöt tuovat myös Check Pointin tutkijoiden mukaan kyberriskit käyttäjien arkeen. Siinä NIS2-direktiivi, EU:n tekoälyasetus (AI Act) ja muu sääntely edellyttävät lisää panostuksia, jotta edes nykyinen kyberturvan taso pystytään osoittamaan jatkuvasti.
Tomi Engdahl says:
EtherCAT täyttää EU:n kyberturvavaatimukset
https://etn.fi/index.php/13-news/18385-ethercat-taeyttaeae-eu-n-kyberturvavaatimukset
Teollisuusautomaation keskeinen kenttäväylä EtherCAT täyttää EU:n uudet kyberturvallisuusvaatimukset ilman teknisiä muutoksia. EtherCAT Technology Group kertoo, että EtherCAT vastaa EU Cyber Resilience Act -asetuksen vaatimuksia turvallisuustasolla 2. Arvio perustuu standardiin IEC 62443, jota pidetään CRA:n keskeisenä teknisenä viitekehyksenä.
Kyberturvallisuus ja kyberresilienssi ovat nousseet keskeiseksi vaatimukseksi EU-lainsäädännössä. Valmistajilta edellytetään riskienhallintaa sekä todennettavia keinoja suojautua kyberuhkia vastaan. EtherCATin kohdalla nämä vaatimukset täyttyvät jo nykyisellä teknologialla, ilman protokollaan tehtäviä muutoksia.
EtherCAT perustuu Ethernetiin, mutta poikkeaa ratkaisevasti IT-verkoista. Se ei käytä IP-protokollaa, johon käytännössä kaikki haittaohjelmat perustuvat. EtherCAT-laitteet käsittelevät Ethernet-kehyksiä suoraan lennossa erityisillä EtherCAT-piireillä. Kaikki muut kuin natiivin EtherCATin mukaiset kehykset hylätään laitetasolla.
Tomi Engdahl says:
https://remion.com/cyber-resilience-act-cra-what-it-means-in-practice-and-how-remion-integrates-it-into-software-development/
Tomi Engdahl says:
https://sbomify.com/2025/02/21/mastering-sbom-generation-with-yocto/
https://archive.fosdem.org/2024/schedule/event/fosdem-2024-3318-spdx-in-the-yocto-project/
Tomi Engdahl says:
https://etn.fi/index.php/tekniset-artikkelit/18711-ssd-stae-tuli-turvapiiri
Tomi Engdahl says:
EU:n CRA tuo uudet kyberturvavaatimukset teollisuustuotteille – mutta suurimmat haasteet löytyvät usein omista prosesseista. Ilman selkeää vastuunjakoa ja jäljitettävyyttä vaatimusten täyttäminen hidastuu.
EU:n CRA-vaatimuksiin valmistautuminen: missä teollisuusvalmistajat yleensä kohtaavat haasteita?
https://www.businessopas.fi/teollisuus/eun-cra-vaatimuksiin-valmistautuminen-missa-teollisuusvalmistajat-yleensa-kohtaavat-haasteita/?fbclid=IwdGRjcARGxw1leHRuA2FlbQEwAGFkaWQAAC_I7vu0v3NydGMGYXBwX2lkDDM1MDY4NTUzMTcyOAABHmySWDgqMyhj5mtsDkHcV8jBcmjvDmWsljcTRMV8SJFLn9wnKKtabggAI8Lf_aem_7rjZMcqk4PBZgPLmoxCQxw&utm_medium=paid&utm_source=fb&utm_id=52540049200487&utm_content=52540049234887&utm_term=52540049203487&utm_campaign=52540049200487
EU:n kyberturvallisuusasetus Cyber Resilience Act (CRA) tuo uusia velvoitteita EU:ssa myytäville digitaalisia ominaisuuksia sisältäville tuotteille.
Kun raportointivaatimukset alkavat vuonna 2026 ja täysi soveltaminen tulee voimaan vuonna 2027, monet teollisuuslaitteiden valmistajat arvioivat parhaillaan, mitä CRA-valmius tarkoittaa heidän tuotteilleen ja tuotekehitysprosesseilleen. Käytännössä suurimmat haasteet eivät kuitenkaan yleensä liity itse sääntelyyn.
Työskennellessäni teollisuusvalmistajien kanssa kyberturvallisuuden ja vaatimustenmukaisuuden parissa näen usein, että projektit alkavat hyvillä aikomuksilla, mutta kohtaavat nopeasti tuttuja ongelmia. Esimerkiksi Legacy-alustoja ei ole välttämättä suunniteltu nykyisiä tietoturvavaatimuksia varten, dokumentaatio voi olla puutteellista, vastuut epäselviä tiimien välillä tai toimittajakomponentit voivat jättää aukkoja integraatiossa.
Legacy-tuotteet ovat usein kaikkein haastavimpia. Uudet järjestelmät voidaan suunnitella alusta alkaen nykyisten kyberturvallisuusvaatimusten mukaisesti, mutta kentällä jo käytössä olevia pitkäikäisiä lippulaivatuotteita ei voida yksinkertaisesti pysäyttää laajoja arkkitehtuurimuutoksia varten – vaikka sääntelyvaatimukset kehittyvät.
Toinen yleinen haaste on organisaation sisäinen linjaus. Tuotekehitys, IT ja tuotejohto voivat tulkita kyberturvallisuusvaatimuksia eri tavoin. Ilman selkeää vastuunjakoa ja priorisointia keskustelu vaatimustenmukaisuudesta voi helposti jäädä teoreettiseksi.
Lopulta kyse ei ole niinkään tarkistuslistoista vaan jäljitettävyydestä: siitä, että vaatimusten, suunnitteluratkaisujen, toteutuksen ja testauksen välillä on selkeä yhteys. Standardit, kuten IEC 62443, tarjoavat hyödyllisiä suuntaviivoja teollisuusjärjestelmille, mutta varsinainen työ on niiden soveltamisessa olemassa oleviin tuotteisiin ja kehitysprosesseihin.
Kun CRA- ja IEC 62443 -vaatimuksia lähestytään käytännönläheisesti ne eivät ainoastaan varmista vaatimustenmukaisuutta, vaan voivat samalla vahvistaa tuotteiden kyberturvallisuutta ja parantaa tuotekehitysprosesseja.
Tomi Engdahl says:
EU:n Cyber Resilience Act – keskeinen aikataulu
• 10. joulukuuta 2024: EU:n Cyber Resilience Act astuu voimaan.
• 11. syyskuuta 2026: Valmistajien on aloitettava aktiivisesti hyödynnettyjen haavoittuvuuksien ja vakavien kyberturvallisuuspoikkeamien raportointi.
• 11. joulukuuta 2027: CRA:n täysimääräiset vaatimukset koskevat kaikkia EU:ssa myytäviä digitaalisia ominaisuuksia sisältäviä tuotteita.
Tomi Engdahl says:
EU CRA and IEC 62443 compliance: what nobody tells you (until costs go off the rails)
https://proekspert.com/blog/embedded-systems/eu-cra-and-iec-62443-compliance-what-nobody-tells-you-until-costs-go-off-the-rails/?fbclid=IwVERDUARGx8xleHRuA2FlbQIxMABzcnRjBmFwcF9pZAwzNTA2ODU1MzE3MjgAAR5ndWYxU3oLg5SSU_keSAxQvbHpl3Iv9BSFF81wuDJrq13OhQIFLNLbcW6sIg_aem_GLKhlarajTJ01eptGaUE1g
Here’s what tends to come up repeatedly with industrial manufacturers:
Legacy platforms not designed for security – documentation that’s patchy at best.
Cybersecurity compliance requirements and feature discussions that turn into internal debates between R&D, IT, product, and management.
Suppliers and partners say their bits are “covered,” but gaps multiply when you try to connect the dots.
There’s plenty of technically excellent cybersecurity advice out there; but credible proof of what works for industrial devices under real-world conditions is much harder to find.
A number of manufacturers have already started their CRA gap analyses, certified their operations for ISO 27001, and have a working knowledge of IEC 62443. The challenge is to understand what really works for their product in a business context, because this is where decisions become complicated:
Architectural questions sit at the integration and firmware level, especially when your product is part platform, part client customization, and you still carry the core responsibility.
Multiple generations of products create risk. New builds can fit with modern cybersecurity compliance requirements by design; years-old platforms force you to weigh what’s necessary and what’s practical to change.
Flagship products that are settled in the field and generating good business cannot be tied up for major rework. At the same time, you cannot afford to ignore potential vulnerabilities, lose track of who owns which fixes, or fall behind competitors that require official compliance with an IEC 62443 standard or EU CRA requirements.
Tomi Engdahl says:
Where most compliance efforts fall short
Audit readiness depends on hands-on know-how. You need someone who understands your systems in detail. External advice is only as useful as your team’s ability to connect it to what’s running in production.
Evidence matters more than theory. Every compliance requirement needs to tie back to real features or test cases, so that when you really need to trace back to the source of an issue you have tools to do it efficiently.
Flexible controls are critical. Adding new security controls might look good on paper, but if it slows down your operations or causes other frictions in practice, you gain nothing.
Traceability is non-negotiable. Documentation needs to reflect actual processes and changes, not paperwork patched up at the last minute.