Wat is IEC 62443-3-3?
IEC 62443-3-3 is de internationale norm uit de IEC 62443-reeks die de technische security-eisen vastlegt waaraan een compleet industrieel automatiserings- en besturingssysteem (IACS) moet voldoen, gekoppeld aan vier security levels (SL). De norm bevat 51 systeemeisen (system requirements, SR), verdeeld over zeven foundational requirements, en geldt voor systemen zoals een SCADA-omgeving, een DCS of een verzameling PLC’s met HMI’s en servers. Met IEC 62443-3-3 kunnen leveranciers, integrators en asset owners eenduidig vastleggen welk beveiligingsniveau een systeem technisch kan halen.
🧠 Wat regelt IEC 62443-3-3 precies?
IEC 62443-3-3 verscheen in augustus 2013 als editie 1.0, met een correctieblad uit april 2014. CENELEC nam de tekst in 2019 ongewijzigd over als EN IEC 62443-3-3:2019, in Nederland verkrijgbaar via NEN. Editie 1 is nog altijd de geldende versie. De IEC heeft 2027 als stabiliteitsdatum vastgesteld: tot dan blijft de tekst in principe ongewijzigd.
De norm kijkt naar het systeem als geheel: de combinatie van servers, werkstations, netwerk en besturingen binnen een zone. Per eis staat vast vanaf welk security level die geldt. Zo ontstaat de SL-C (capability): het niveau dat het systeem met zijn ingebouwde functies kan halen.
Twee principes lopen door de hele norm:
- Essentiële functies gaan voor - beveiliging mag nooit leiden tot verlies van bescherming met gevolgen voor gezondheid, veiligheid of milieu. Een accountblokkade na foute inlogpogingen mag een operator bijvoorbeeld niet buitensluiten van een noodstop, en authenticatie mag het activeren van een veiligheidsfunctie niet vertragen.
- Compenserende maatregelen mogen - kan het systeem een eis niet zelf invullen, dan mag een externe component dat doen, zoals een firewall of een centrale SIEM. De keuze daarvoor volgt de risicobeoordeling uit IEC 62443-3-2.
🔧 Welke zeven foundational requirements bevat de norm?
De 51 systeemeisen zijn gegroepeerd onder de zeven foundational requirements (FR) uit IEC 62443-1-1:
| FR | Naam | Aantal SR | Voorbeelden van systeemeisen | Typische maatregelen |
|---|---|---|---|---|
| FR 1 | Identification and authentication control (IAC) | 13 | SR 1.1 gebruikersauthenticatie, SR 1.7 wachtwoordsterkte, SR 1.13 toegang via niet-vertrouwde netwerken | User-Based Access Control, MFA, unieke gebruikersaccounts |
| FR 2 | Use control (UC) | 12 | SR 2.1 autorisatie, SR 2.5 sessievergrendeling, SR 2.8 auditeerbare gebeurtenissen, SR 2.12 onweerlegbaarheid | Least Privilege, RBAC, Logging |
| FR 3 | System integrity (SI) | 9 | SR 3.1 integriteit van communicatie, SR 3.2 bescherming tegen malware, SR 3.4 integriteit van software | Whitelisting, Application Control, Antivirus |
| FR 4 | Data confidentiality (DC) | 3 | SR 4.1 vertrouwelijkheid, SR 4.2 veilig wissen, SR 4.3 gebruik van cryptografie | Encryptie van verkeer, wachtwoorden en data |
| FR 5 | Restricted data flow (RDF) | 4 | SR 5.1 netwerksegmentatie, SR 5.2 bescherming van zonegrenzen | Netwerksegmentatie, Protocol Filtering, Firewalls |
| FR 6 | Timely response to events (TRE) | 2 | SR 6.1 toegang tot auditlogs, SR 6.2 continue monitoring | Anomaliedetectie, Security Monitoring, SIEM, Incident Response |
| FR 7 | Resource availability (RA) | 8 | SR 7.1 bescherming tegen DoS, SR 7.3 back-up, SR 7.7 minimale functionaliteit, SR 7.8 componenteninventaris | Bescherming tegen DDoS, back-ups, Redundantie, High Availability |
Opvallend is wat er níet in staat: patchmanagement is geen systeemeis in 3-3, maar wordt behandeld in IEC TR 62443-2-3 en in de procesnormen voor asset owners en serviceproviders. Wel vraagt SR 3.4 om controle op de integriteit van software, wat bij het installeren van patches direct relevant is.
📊 Hoe werken security levels en requirement enhancements?
Elke systeemeis heeft een basistekst en vaak een of meer requirement enhancements (RE) die pas op een hoger niveau verplicht worden. Bijlage B van de norm koppelt elke SR en RE aan SL 1 tot en met 4. De niveaus zijn gedefinieerd op basis van de aanvaller:
| SL | Beschermt tegen | Voorbeeld SR 1.1 (authenticatie van gebruikers) |
|---|---|---|
| SL 1 | Toevallige of onbedoelde overtreding | Gebruikers worden geïdentificeerd en geauthenticeerd |
| SL 2 | Opzettelijke aanval met eenvoudige middelen, beperkte capaciteit, algemene kennis en lage motivatie | Plus: elke gebruiker uniek identificeerbaar (RE 1) |
| SL 3 | Gerichte aanval met geavanceerde methoden, IACS-specifieke kennis en matige middelen en motivatie | Plus: MFA voor toegang via niet-vertrouwde netwerken (RE 2) |
| SL 4 | Gerichte aanval met geavanceerde methoden, IACS-specifieke kennis, uitgebreide middelen en hoge motivatie, bijvoorbeeld van statelijke actoren | Plus: MFA voor álle netwerken (RE 3) |
De meeste basiseisen gelden al op SL 1, maar niet alle. Zo worden SR 1.2 (authenticatie van apparaten en softwareprocessen), SR 1.8 (PKI-certificaten), SR 3.9 (bescherming van auditinformatie), SR 4.2 (veilig wissen van gegevens), SR 6.2 (continue monitoring) en SR 7.8 (componenteninventaris) pas vanaf SL 2 gevraagd. SR 2.7 (beperking van gelijktijdige sessies) en SR 2.12 (onweerlegbaarheid) komen zelfs pas op SL 3 in beeld.
Een security level is bovendien geen enkel getal maar een vector met één waarde per FR, in de volgorde IAC, UC, SI, DC, RDF, TRE, RA. Een zone kan bijvoorbeeld SL-T = {2 2 2 1 3 2 3} krijgen: streng op datastromen en beschikbaarheid, licht op vertrouwelijkheid. Dat past bij OT, waar beschikbaarheid meestal zwaarder weegt dan geheimhouding.
| Begrip | Betekenis | Wie bepaalt het? |
|---|---|---|
| SL-T (target) | Benodigd niveau per zone of conduit | Asset owner, via IEC 62443-3-2 |
| SL-C (capability) | Niveau dat het systeem kan halen | Leverancier of integrator, via 3-3 |
| SL-A (achieved) | Niveau dat in de praktijk is bereikt | Toetsing na configuratie en ingebruikname |
🏭 Hoe ziet IEC 62443-3-3 eruit in een OT-installatie?
| Component | Voorbeelden van 3-3-eisen |
|---|---|
| SCADA-server en HMI | Individuele accounts (SR 1.1), rollen per operator (SR 2.1), systeembrede audittrail met tijdstempels (SR 2.8, SR 2.11) |
| PLC en controllers | Authenticatie van apparaten en softwareprocessen (SR 1.2), integriteit van communicatie (SR 3.1), uitschakelen van ongebruikte poorten en diensten (SR 7.7) |
| Historian | Versleuteld verkeer naar de kantoorzone (SR 4.1, SR 4.3), bescherming tegen overbelasting (SR 7.1) |
| Engineering Station | Applicatiewhitelisting tegen malware (SR 3.2), beperking van USB-media (SR 2.3), rechtenbeheer via RBAC (SR 2.1) |
| Zonegrens | Deny-by-default-regels (SR 5.2 RE 1), segmentatie van kritieke netwerken (SR 5.1) |
Bij SR 5.2 ziet u ook de voorzichtigheid van de norm: een zonegrens mag op hogere niveaus in island mode gaan of bij uitval dichtvallen (fail close), maar nooit zo dat een veiligheidssysteem erdoor wordt gehinderd.
🔄 Hoe verhoudt 3-3 zich tot de andere delen van IEC 62443?
- IEC 62443-1-1 - levert de begrippen en de zeven foundational requirements.
- IEC 62443-3-2 - bepaalt via een risicobeoordeling de zones, conduits en de SL-T; 3-3 levert daarna de eisen om dat niveau te halen.
- IEC 62443-4-2 - vertaalt de systeemeisen naar afzonderlijke componenten (SL-C van één PLC of switch).
- IEC 62443-4-1 - beschrijft het veilige ontwikkelproces van de leverancier.
- IEC 62443-2-4 - stelt eisen aan de integrator die het systeem bouwt en onderhoudt.
Een systeem kan worden gecertificeerd via ISASecure SSA (System Security Assurance). Daarvoor moet het aan de systeemeisen van 3-3 voor het geclaimde security level én aan het ontwikkelproces van 4-1 voldoen, beoordeeld door een geaccrediteerde certificeerder. Ook sectorkaders bouwen op 3-3: NAMUR Open Architecture baseert de beschermingsprofielen in NE 177 op de security levels uit deze norm.
🧭 Hoe past u IEC 62443-3-3 stap voor stap toe?
- Inventariseer het systeem - leg vast welke assets, netwerken en verbindingen binnen de afbakening vallen.
- Deel in zones en conduits in volgens het Zone and Conduits-model en een risicobeoordeling conform IEC 62443-3-2.
- Bepaal de SL-T-vector per zone; in de praktijk is SL 2 vaak het uitgangspunt en SL 3 gebruikelijk voor kritieke zones en externe toegang.
- Vraag de SL-C op bij leverancier of integrator, per FR, en vergelijk die met de SL-T.
- Dicht de gaten met compenserende maatregelen, zoals een industriële firewall, jumpserver of centrale logging.
- Toets de SL-A na oplevering met een configuratiecontrole of pentest, en herhaal dat na grote wijzigingen.
Voor Nederlandse organisaties is dit geen theorie meer. De Cyberbeveiligingswet is sinds 15 augustus 2026 van kracht en eist passende maatregelen voor netwerk- en informatiesystemen, ook in OT. IEC 62443-3-3 is een herkenbare manier om dat voor besturingssystemen aantoonbaar in te vullen. Leveranciers van producten krijgen daarnaast met de Cyber Resilience Act te maken, die vanaf 11 december 2027 volledig van toepassing is.
✅ Wat levert implementatie op?
- Meetbare technische eisen - u kunt in een bestek precies benoemen welke SR’s en RE’s u verwacht.
- Ondersteuning van Defense in Depth - de zeven FR’s dekken identiteit, integriteit, datastromen en beschikbaarheid.
- Toepasbaar per zone - u hoeft niet de hele fabriek op hetzelfde niveau te brengen.
- Aansluiting op andere kaders - ondersteunt compliance met NIS2, ISO 27001 en het NIST CSF.
❓ Veelgestelde vragen
Hoeveel eisen bevat IEC 62443-3-3?
IEC 62443-3-3 bevat 51 systeemeisen, verdeeld over zeven foundational requirements. Daarnaast heeft een groot deel van die eisen requirement enhancements die alleen op hogere security levels gelden. Hoe meer enhancements van toepassing zijn, hoe hoger het security level dat een systeem kan halen.
Is IEC 62443-3-3 verplicht?
IEC 62443-3-3 is als norm niet wettelijk verplicht. Wetten zoals NIS2 en de Cyberbeveiligingswet vragen wel om passende beveiligingsmaatregelen, en IEC 62443-3-3 is een gangbare manier om die voor industriële besturingssystemen aan te tonen. Veel asset owners nemen de norm daarom op in hun inkoopvoorwaarden.
Wat is het verschil tussen IEC 62443-3-3 en IEC 62443-3-2?
IEC 62443-3-2 beschrijft hoe u een systeem met een risicobeoordeling indeelt in zones en conduits en per zone het benodigde security level (SL-T) bepaalt. IEC 62443-3-3 beschrijft welke technische eisen een systeem moet vervullen om een bepaald security level te halen. De twee normen worden daarom vrijwel altijd samen gebruikt.
Voor wie is IEC 62443-3-3 bedoeld?
IEC 62443-3-3 is in de eerste plaats bedoeld voor leveranciers en integrators die industriële besturingssystemen ontwerpen en bouwen. Asset owners gebruiken de norm om eisen te stellen bij aanbestedingen en om geleverde systemen te toetsen. Ook auditors en certificeerders werken met de systeemeisen uit deze norm.
Kan een systeem IEC 62443-3-3-gecertificeerd worden?
Een besturingssysteem kan tegen IEC 62443-3-3 worden gecertificeerd, bijvoorbeeld via het ISASecure SSA-programma. Daarbij toetst een geaccrediteerde instelling de systeemeisen uit 3-3 voor het geclaimde security level en het ontwikkelproces volgens IEC 62443-4-1. Het certificaat vermeldt het security level dat het systeem kan halen, niet het niveau van uw eigen installatie.
Wat is een security level vector in IEC 62443-3-3?
Een security level vector in IEC 62443-3-3 is een reeks van zeven getallen, één per foundational requirement, die samen het beveiligingsniveau van een zone of systeem beschrijven. Zo kan een zone streng zijn op datastromen en beschikbaarheid en minder streng op vertrouwelijkheid. Daardoor sluit het niveau beter aan op het werkelijke risico.
📌 Samengevat
IEC 62443-3-3 legt met 51 systeemeisen en vier security levels vast welke technische beveiliging een industrieel besturingssysteem als geheel moet bieden. Samen met de risicobeoordeling uit IEC 62443-3-2 en de componenteisen uit IEC 62443-4-2 vormt de norm de technische ruggengraat voor het beschermen van OT-systemen, zonder dat beveiliging ten koste gaat van veiligheid en beschikbaarheid.