Security Baseline: NSM Grunnprinsipper & EU Regulation

Updated Jul 28, 2026 History
securitycompliancensmcranis2owasp

Security Baseline: NSM Grunnprinsipper & EU Regulation

When to use it: when you need to know what "secure enough" actually means for a
Norwegian or EU-facing product — which regulation bites, when, and which concrete
engineering controls satisfy it. Reach for it when scoping security work, answering a
customer security questionnaire, preparing for CRA or NIS2/digitalsikkerhetsloven, adding
an SBOM, writing a vulnerability disclosure policy, or deciding how much hardening a
service warrants. Complements Red Team: Four Adversaries, Kill-Chain or It's Locked,
which attacks a system — this one tells you what to build in the first place.

Two different things get called "security requirements": frameworks that tell you what
good looks like, and law that tells you what you must do or be fined. Keep them apart.
NSM's grunnprinsipper are the former; CRA and NIS2 are the latter.

What actually applies to you

Regime Who Status / dates Teeth
NSM grunnprinsipper v2.1 Anyone; written for critical-function operators Guidance, June 2024. Not law — but the basis sector regulators build on None directly; cited in contracts and audits
Digitalsikkerhetsloven Norwegian essential/important entities In force 1 Oct 2025 (implements NIS1) Supervisory
NIS2 (via digitalsikkerhetsloven) ~5 000 Norwegian entities, up from ~600 NIS2-adapted amendments scheduled 1 Jul 2026, registration deadline 1 Oct 2026, sector audits from ~mid-2027 Up to 4 % of global turnover; ~3 MNOK cap for public bodies
Cyber Resilience Act Anyone placing "products with digital elements" on the EU market — including software Reporting obligations 11 Sep 2026; full obligations 11 Dec 2027 Up to €15 M or 2.5 % of global turnover
GDPR Personal data In force Up to €20 M / 4 %
DORA Financial entities and their ICT providers In force Jan 2025 Sector supervisory

⚠️ Verify the NIS2 date before you rely on it. Norway is EEA, not EU, so NIS2 must be
incorporated into the EEA agreement before Norwegian implementation. That incorporation was
still pending in mid-2026 and the 1 July 2026 target has slipped before. Check
nsm.no for the current position rather than trusting a table — including
this one.

The trap worth naming: CRA scope is much wider than people assume. It is not an IoT law.
Commercially supplied software is a "product with digital elements". If you ship a SaaS
product into the EU with any downloadable or on-premise component, assume you are in scope
until a lawyer says otherwise.

The engineering baseline — NSM's 21 principles

Four categories, 21 principles, 118 measures. The value is the ordering: you cannot protect
what you have not mapped, and category 1 is where almost everyone is weakest.

1. Identifisere og kartlegge

# Principle What it means in a repo
1.1 Kartlegg styringsstrukturer, leveranser og understøttende systemer A written service catalogue: what this system does, who owns it, what it depends on
1.2 Kartlegg enheter og programvare Dependency inventory — this is your SBOM, and it is also a CRA obligation
1.3 Kartlegg brukere og behov for tilgang Documented roles and what each may reach

2. Beskytte og opprettholde

# Principle Concrete control
2.1 Ivareta sikkerhet i anskaffelses- og utviklingsprosesser Security in the SDLC: threat model at design, review gate before merge
2.2 Etabler en sikker IKT-arkitektur Segmentation, least privilege between tiers, no flat networks
2.3 Ivareta en sikker konfigurasjon Hardened, reproducible config as code; secure by default
2.4 Beskytt virksomhetens nettverk Deny-by-default ingress/egress
2.5 Kontroller dataflyt Know and constrain what leaves the system
2.6 Ha kontroll på identiteter og tilganger MFA, scoped tokens, no shared accounts, revocation that works
2.7 Beskytt data i ro og i transitt TLS everywhere, encryption at rest, managed keys
2.8 Beskytt e-post og nettleser SPF/DKIM/DMARC, CSP and security headers
2.9 Etabler evne til gjenoppretting av data Backups you have restored from, offline copy
2.10 Integrer sikkerhet i prosess for endringshåndtering Every change reviewed, logged, revertible

3. Oppdage

# Principle Concrete control
3.1 Oppdag og fjern kjente sårbarheter og trusler Automated dependency + container scanning, patch SLA
3.2 Etabler sikkerhetsovervåkning Structured audit logging with retention
3.3 Analyser data fra sikkerhetsovervåkning Alerts a human actually sees; logs nobody reads are theatre
3.4 Gjennomfør inntrengingstester Periodic pentest — see Red Team: Four Adversaries, Kill-Chain or It's Locked

4. Håndtere og gjenopprette

# Principle Concrete control
4.1 Forbered virksomheten på håndtering av hendelser A runbook naming who decides, who communicates, who fixes
4.2 Vurder og klassifiser hendelser Severity scale mapped to legal reporting clocks
4.3 Kontroller og håndter hendelser Contain → eradicate → recover, with evidence preserved
4.4 Evaluer og lær av hendelser Blameless post-mortem feeding back into controls

That last one is the compounding layer applied to security: an
incident you do not learn from you have merely survived.

CRA: the obligations that land on engineers

Most CRA compliance is paperwork owned by someone else. Four parts are yours.

1 — SBOM. Annex I Part II requires a machine-readable SBOM covering at least top-level
dependencies, kept current for the entire support period. No format is mandated; use
CycloneDX or SPDX, both of which market surveillance authorities recognise.

# Generate in CI, attach to every release artifact — not a one-off document
syft dir:. -o cyclonedx-json > sbom.cdx.json
grype sbom:sbom.cdx.json --fail-on high

The SBOM requirement lives inside the vulnerability-handling rules, which tells you the
intent: it is an operational tool for answering "am I affected?" in minutes, not a document
you file. If yours cannot answer that question, it is not doing its job.

2 — Secure by default. The product ships with a secure configuration and a minimised
attack surface, and can be reset to its original state. No default credentials. Nothing
sensitive on by default. Debug endpoints off in production builds.

3 — Vulnerability handling as a lifecycle. Remediate without undue delay, test and review
regularly, and publish information about fixed vulnerabilities. A coordinated disclosure
policy and a monitored contact are part of the obligation:

/.well-known/security.txt
  Contact: mailto:security@example.com
  Policy: https://example.com/security-policy
  Preferred-Languages: no, en
  Expires: <ISO-8601, keep it in the future>

4 — The reporting clocks. From 11 September 2026, actively exploited vulnerabilities
and severe incidents must be notified:

Deadline What
24 hours Early warning
72 hours Full notification
14 days Final report, after a corrective measure is available

Twenty-four hours is a detection requirement disguised as a reporting one. If you cannot
tell that you are being exploited, the clock is already running and you do not know it. This
is why 3.2/3.3 above are not optional.

OWASP Top 10:2025

The category list changed. 2025 is current (announced Nov 2025, finalised Jan 2026) and it
is not the 2021 list people still review against — two categories are new and SSRF moved.

ID Category Change since 2021
A01 Broken Access Control Retained #1; now absorbs SSRF
A02 Security Misconfiguration Up from #5
A03 Software Supply Chain Failures New — expanded from "vulnerable components"
A04 Cryptographic Failures Down from #2
A05 Injection Down from #3
A06 Insecure Design Down from #4
A07 Authentication Failures Renamed from "Identification and Authentication Failures"
A08 Software or Data Integrity Failures Retained
A09 Security Logging & Alerting Failures Renamed — alerting is now explicitly in scope
A10 Mishandling of Exceptional Conditions New — failing open, swallowed errors, happy-path-only logic

Check A03 and A10 explicitly. Neither existed as a category before, so any review process
carrying the old list forward has a structural blind spot there — not because reviewers are
careless, but because there was nothing to prompt them.

A03 is also where this baseline joins up: the CRA SBOM duty and NSM principle 1.2 are the same
control seen from three directions.

Verification: OWASP ASVS 5.0

Frameworks say what to achieve; ASVS gives you testable requirements. Version 5.0.0 (May 2025)
is ~350 requirements across 17 chapters, up from 286 across 14, with passwords realigned to
NIST SP 800-63, post-quantum considerations added, and outdated practices removed.

  • L1 — deliberately lowered entry bar. The first layer of defence; where to start.
  • L2 — standard practice for anything holding real data. This is the default target.
  • L3 — high assurance, for systems where compromise is severe.

Pick a level, write it in the constitution, and make it a review dimension rather than an
annual audit. "We follow ASVS" with no level named means nothing.

The recipe: what to actually add

# Supply chain — in CI, on every build
syft / cdxgen        → SBOM, attached to the release
grype / trivy / osv  → fail the build on known-exploitable
gitleaks             → secrets, on pre-commit AND in CI
cosign               → sign artifacts, verify at deploy

# Runtime
TLS everywhere · deny-by-default egress · scoped short-lived tokens
structured audit log: who, what, when, from where — with retention
security headers + CSP · SPF/DKIM/DMARC on the sending domain

# Paper that engineering owns
/.well-known/security.txt      · coordinated disclosure policy
incident runbook with the 24h/72h/14d clocks written into it
restore-tested backups, with the date of the last successful restore

Gotchas

Backups you have never restored are not backups. Principle 2.9 says gjenoppretting —
recovery — not sikkerhetskopiering. Record the date of the last successful restore drill; if
it is blank, treat the control as failed.

Do not conflate NSM grunnprinsipper with compliance. They are excellent engineering
guidance and they are not law. Following all 118 measures does not make you NIS2-compliant,
and being NIS2-compliant does not mean you followed them. Track the two separately.

The 24-hour CRA clock starts at awareness, not at triage. "We were still investigating" is
not a defence. Decide in advance who is authorised to file an early warning on incomplete
information — that decision made at 02:00 during an incident is the wrong time.

Scope creep is a real risk here, in both directions. Regulation is the one area where
restraint does not apply to safety controls —
input validation, error handling, authorization, and audit logging are load-bearing. But it
absolutely applies to compliance machinery: a bespoke policy-management system for a
five-person team is over-building. Buy the boring thing or use a checklist.

Security theatre passes audits. Logs nobody reads, an SBOM generated once and committed,
a disclosure address routing to an unmonitored inbox — all of these satisfy a checkbox and
none of them work. The test for every control: what would tell us it failed?

Automating it in the pipeline

The agentic spec-kit extension ships this
baseline as templates/security-baseline.md and acts on it:

  • /speckit.agentic.security establishes the feature's trust boundaries, walks the Top 10:2025
    against them, and appends the resulting controls to tasks.md as SEC-* tasks — in the same
    phase as the code they protect, before implementation.
  • /speckit.agentic.verify reviews the diff against the same list and treats a checked-off
    SEC- task with no matching control as a blocker.

The point of both: a control that is a task gets built; a control that is a review comment
does not.

See also