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

⚠️ 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

2. Beskytte og opprettholde

3. Oppdage

4. Håndtere og gjenopprette

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:

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.

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?

See also

• Red Team: Four Adversaries, Kill-Chain or It's Locked — adversarial validation of what this baseline builds
• The Compounding Layer — incident learnings that become enforced rules
• Rails Production Playbook — deny-by-default conventions in a concrete stack
• NSM grunnprinsipper for IKT-sikkerhet — the source, v2.1 (June 2024)
• Cyber Resilience Act and CRA reporting obligations — European Commission
• OWASP ASVS — v5.0.0, May 2025