---
title: "Compliance & Implementation"
description: COMPLIANCE CROSSWALK How do the controls in this guide map across multiple compliance frameworks (compliance crosswalk)? The same set of controls earns credit under multiple frameworks. The crosswalk in Figure 7 maps six control areas introduced in this guide against…
url: "https://bifrostconnect.com/knowledge-center/compliance-and-implementation/"
updated: "2026-07-10"
category: Best Practice Guide
---

# Compliance & Implementation

COMPLIANCE CROSSWALK How do the controls in this guide map across multiple compliance frameworks (compliance crosswalk)? The same set of controls earns credit under multiple frameworks. The crosswalk in Figure 7 maps six control areas introduced in this guide against five frameworks: NIS2 Article 21, Lov om styrket beredskab i energisektoren and BEK 260, IEC 62443-3-3, NIST SP 800-82 Rev. 3, and NIST SP 800-207. Each non-empty cell carries the specific clause reference, not just a checkmark. Empty cells are deliberate. They mean the framework does not address the principle at a clause level that this guide is willing to cite verbatim. Where a framework offers a closely matching control without an exact verbatim clause, the cell cites the most specific available clause and the descriptor remains conservative. Supply-chain hygiene for the IEC 62443 family is anchored to IEC 62443-2-4:2024 (service-provider programme requirements) rather than to 62443-3-3, because the service-provider programme is the system-of-systems requirement most directly applicable to third-party access governance.

| Control area | NIS2 Art. 21 | Lov om styrket beredskab i energisektoren / BEK 260 | IEC 62443-3-3:2019 | NIST SP 800-82 | NIST SP 800-207 |
| --- | --- | --- | --- | --- | --- |
| **1. Zero Standing Privilege** (Privilege expires) | Art. 21(2)(i) access control policies | § 52 stk. 1 nr. 1 + § 55 stk. 2 adgangskontrol; ophører ved opgavens afslutning | SR 2.1 + RE 2 authorization enforcement; permission mapping to roles | § 6.2.10 remote access OT overlay: removing access when no longer required | Tenet 3 per-session access |
| **2. Ad-hoc access beats standing** (No always-on paths) | Art. 21(2)(e) network and information system security | § 62 segmentering og logisk adskillelse | SR 5.1 network segmentation | § 6.2.1.3 network architecture; deny-all default | Tenet 2 all comms secured regardless of location |
| **3. Layered controls** (Defense in depth) | Art. 21(2)(b) incident handling | § 55 stk. 3 mulighed for at afbryde og terminere adgang | SR 5.1 network segmentation (zone boundary) | AC-17(9) remote access; disconnect/disable | Tenet 6 dynamic, strictly enforced authentication |
| **4. Session evidence** (Recorded, reviewed) | Art. 21(2)(b)+(f) incident handling; effectiveness | § 66 stk. 2 nr. 2 logning og opbevaring af adgangshændelser | SR 6.1 audit log accessibility | § 5.2.3.2 centralized logging | Tenet 7 monitor posture; collect info; improve |
| **5. Supply-chain hygiene** (Vendors are assets too) | Art. 21(2)(d) + para 3 supply-chain security | § 29 + § 30 + § 31 leverandørstyring; krav til tredjepart | IEC 62443-2-4 SP.07 service provider security program | § 6.2.10 third-party access | n/a outside ZTA scope |
| **6. Offline-capable design** (Works when internet doesn't) | Art. 21(2)(j) MFA / continuous authentication | § 53 flerfaktorautentificering | SR 1.1 + RE 2 identification and authentication; unique IDs | § 6.2.10 identification and authentication | Tenet 6 authZ enforced before access |

  *Figure 7. Compliance crosswalk. Six control areas by five frameworks, with the specific clause reference in each non-empty cell. Empty cells are deliberate and explicitly marked. Product-specific coverage mapping lives in the companion BifrostConnect Implementation Guide (Del 2).*     IMPLEMENTATION PRIORITY What is the recommended implementation priority and phased plan for third-party OT access controls? A reader finishing the crosswalk typically asks a practical question: what do I do on Monday morning? This guide's answer is a vendor-neutral maturity staging. The ordering is deliberately technology-agnostic; it reflects the natural sequence in which controls stabilise on top of each other. A competitor to the publisher of this guide could adopt the same sequence without change.

#### PHASE 1 - STOP THE BLEEDING (0-30 DAYS)

 Inventory every third-party access path currently in use: named vendor, purpose, entry point, protocol, and whether MFA is enforced. Remove or disable any standing VPN account for which no current, approved work exists. Disable inbound listening ports that are not accounted for in the inventory. This phase is discovery and containment; it does not require new procurement.

#### PHASE 2 - ESTABLISH THE PATTERN (30-90 DAYS)

 Introduce a session broker, MFA on every session, and per-session approval. Replace shared vendor credentials with named identities bound to the broker. Enforce a time-out policy measured in hours. At this phase, the access path may still be imperfect; the goal is to make every session a discrete, identifiable, revocable event. These windows assume an organisation with existing identity and logging foundations; a site starting from zero should treat the same steps as a longer programme and sequence them over a realistic horizon.

#### PHASE 3 - EVIDENCE AND MONITORING (90-180 DAYS)

 Turn on session recording and route logs to the asset owner's SIEM or SOC. Tune alarming on specific OT anomalies (PLC stop attempts, unauthorised code upload, command sequences outside ticketed work). Institutionalise incident response for detected anomalies: session revocation, site-owner notification, incident record. A 90-to-180-day window is realistic only where log collection already exists; building SIEM or SOC visibility from nothing is itself a multi-quarter effort and should be planned as one.

#### PHASE 4 - PROGRAM MATURITY (180+ DAYS)

 Move from per-session controls to programme-level controls. Vendor onboarding checklists, contract clauses for security posture, background checks where the regulatory regime allows it, vendor-specific threat modelling, and joint incident response playbooks with named vendors. This phase is the substance of IEC 62443-2-4:2024 and NIS2 Article 21(2)(d) read together.