Telecom compliance: NESAS, SCAS, NIS2 & the 5G Toolbox

3GPP TS 33.501, GSMA NESAS/SCAS, EU NIS2, the EU 5G Toolbox and the NSA/CISA 5G-cloud guidance all press a 5G core on one question: which network function is on this connection, can a third party verify it, and can you attribute what it did and cut it off?

Inside one operator, mutual TLS and OAuth2 answer that well at the handshake. But NF discovery and addressing ride DNS, roaming trust crosses opaque IPX hubs, and every certificate chain terminates at an operator-private CA no outside party can check. A routable, DNSSEC/DANE-provable, one-call-revocable IPv6 /128 per NF, derived from the key the NF already holds, adds a second, independent layer that produces the binding, the log, the attribution and the kill-switch those frameworks want as evidence. This page is the honest map of where that evidence fits (and, just as important, where it does not).

What every framework is really asking

Read the 5G-core security frameworks side by side and the same three questions surface, phrased in a dozen vocabularies:

• Identity: which NF (or SEPP, or roaming peer) is on the other end of this SBI or N32 connection, and can a third party (a roaming partner, an IPX, a regulator) verify it without trusting your operator-private CA?
• Attribution & monitoring: what did that party do, to which destinations, who is enumerating your NRF, and can you produce a continuous, non-repudiable record on an incident-reporting clock?
• Response: when one NF is compromised or one interconnect turns hostile, can you contain it, provably and fast, across every operator, not one CRL at a time?

None of these is a logging problem you fix with more log lines. They are identity problems. 3GPP already binds a strong identity into the NF certificate (TS 33.310 §6.1.3c mandates a subjectAltName URI-ID of urn:uuid:<nfInstanceId>), but that certificate is signed by an operator-private CA, verifiable only after bilateral cross-certification. It is not a routable identity that survives NAT/roaming/IPX, and under the operator-PKI model it cannot be revoked across an operator boundary at any useful speed. Whisper's job here is to project that same identity, the same nfInstanceId from the NF's existing key, into an address that is globally verifiable and revocable, then let the standard toolchain read the evidence off it.

Three verdicts, stated up front

Before a single row of the map, here's the grading rule, because a telecom-compliance page that claimed to "certify your NF under NESAS" would be lying. Whisper is a network primitive. Against a given control it does exactly one of three things, and we mark which:

The evidence: real and shipped

Everything this page grades DIRECT-ADDITIVE rests on primitives that exist and answer today. Each is checkable with dig, curl, or one control-plane call over the public API: POST https://graph.whisper.security/api/query with your X-API-Key.

An NF-derived /128 identity

Every 5G NF already holds a key: the private half of the mTLS certificate it presents on the SBI, the one whose subjectAltName carries urn:uuid:<nfInstanceId>. Whisper derives a deterministic IPv6 /128 from that key's public SubjectPublicKeyInfo, with the nfInstanceId as the domain separator. The address is tenant-bound (unlinkable across operators to an outsider), DNSSEC-anchored, DANE-EE 3 1 1 pinned to the same certificate the NF already speaks, and RDAP-registered. Re-deriving from the same key and nfInstanceId yields the same /128: nothing new to store, no second CA to stand up, nothing to steal that would let a scraper forge it. The /128 drops straight into the NF's NFProfile ipv6Addresses: no NRF API change.

# Provision an NF identity from the key it already holds (control plane, live).
# identity_public_key is the base64 SPKI of the NF's existing SBI mTLS key.
CALL whisper.agents({op:'connect', args:{
  tier:'wireguard',
  identity_public_key:'<base64 SPKI of the NF key>',
  device_id:'3f2504e0-4f89-11d3-9a0c-0305e82c3301'   // the nfInstanceId, already in the cert SAN as urn:uuid:…
}}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error
# -> deterministic /128 out of 2a04:2a01::/32 + a WireGuard config.
#    Same key + nfInstanceId -> same /128 (idempotent). A different nfInstanceId on the
#    same tenant -> 409; a non-string device_id -> 400 + ProblemDetails. Never an opaque 500.

Per-/128 logs, and who's looking back

Because each NF owns a dedicated /128, every DNS lookup and connection it makes on the SBI is unambiguously its: no shared-IP or NAT'd-pod noise to reconstruct. And because the identity resolves through Whisper's own authoritative DNS and RDAP, you can also ask who is enumerating you, a reconnaissance tripwire the private NRF's out-of-band trust never offered. When reachability at the NRF equals authorization, seeing who is resolving your NF fleet's identities is an early warning that someone is mapping it.

# The NF's OWN outbound activity, per-event: timestamp, kind, destination, decision, bytes
CALL whisper.agents({op:'logs',    args:{agent:'2a04:2a01:5e0::a3f', kind:'conn', from:'-24h'}})

# Reverse observability: WHO resolved this NF's PTR/AAAA/TLSA or hit its RDAP object, and when
CALL whisper.agents({op:'lookups', args:{agent:'2a04:2a01:5e0::a3f', window:'24h'}})
curl -s https://whisper.online/ip/2a04:2a01:5e0::a3f/lookups | jq   # same view, keyless

One-call revoke

Containment, the end of a compromised NF's or a hostile interconnect's reach, is a single call. It tears down the /128, its PTR and its DANE record worldwide at DNS-TTL speed, and the teardown is provable with the same public tools that proved the identity. Kill it everywhere in one TTL, not one CRL per operator.

CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:5e0::a3f'}})
# after the TTL:
dig -x 2a04:2a01:5e0::a3f +short                          # -> empty
curl -s https://whisper.online/verify-identity/2a04:2a01:5e0::a3f   # -> {"is_whisper_agent": false}

The attribution graph

Turning a raw destination (or a suspicious peer egress in your logs) into "known-bad infrastructure" or "clean CDN" is a read-only query against the public graph API. Attribution survives egress rotation because it fingerprints the operator and the tooling (ASN and hosting genealogy for cloud rotation, a JA4/JA3 client fingerprint for a residential-proxy or IPX-fronted swarm), not the ephemeral IP the way an in-plane signaling firewall does.

curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  --data-urlencode "q=CALL whisper.identify('203.0.113.7')"
# -> what the address is, who operates it, threat-intel reputation, relationships:
#    a reproducible, replayable JSON evidence chain your core SOC, PSIRT and a regulator can replay.

The read-only verbs (identify, origins, walk, variants, history) run the same way, over an infrastructure-and-threat-intelligence graph of billions of nodes. That is the enrichment that turns a per-NF egress log into a detection, and names the operator behind a rotating egress that a GT/realm-scoped signaling firewall cannot.

The map, at a glance

Each row is a framework, the control it asks for, our verdict, and the shipped evidence behind it. The deep sections below unpack each group. Read the verdict column first: it is the load-bearing part. Every mapping is additive to the mandated 3GPP mTLS + OAuth2 and the operator PKI; none replaces them.

^¹ COMPLEMENTARY as an embeddable feature that supports the Annex I identity/access-management and logging requirements. It is not a route to CRA conformity, and it does nothing for the SBOM requirement. See the caveats.

DIRECT-ADDITIVE: the four defensible claims, first

Four claims survive hostile review. They are spec-level, they persist after mTLS, OAuth2, signaling firewalls and the SEPP are all in place, and they are where Whisper earns a DIRECT-ADDITIVE verdict. Lead with these; everything else on the page is downstream of them.

1 · DNSSEC + DANE close the DNS-spoofing / rogue-NRF gap (TS 33.501)

This is the least-contestable claim on the page, so it comes first. 3GPP binds the NF's identity into its certificate: the SBA cert profile (TS 33.310 §6.1.3c) mandates a subjectAltName URI-ID of urn:uuid:<nfInstanceId>, ECDSA recommended. But NF and NRF discovery and addressing ride DNS, and TS 33.501 mandates mTLS and OAuth2 without mandating DNSSEC or DANE on that SBA name layer. Spoof the DNS answer under an NF or NRF FQDN and you can redirect a consumer to a rogue NRF, or point it at a forged token-issuer URL. Mutual TLS by itself does not cover the name → address → expected-cert binding that got hijacked one layer down. A DNSSEC-signed zone with a DANE TLSA record pinning the exact certificate the NF already presents closes that gap: the consumer resolves the name, validates the chain to the IANA root, and confirms the served leaf matches the pin before it trusts a token or opens a session.

2 · Cryptographic attribution for incident handling & reporting (NIS2, SCAS)

NIS2 (Directive (EU) 2022/2555) obliges essential and important entities, telecoms squarely among them, to handle incidents (Art.21(2)(b)) and to report them on a hard clock (Art.23): an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month. Every one of those filings needs a defensible who and where. The attribution graph produces exactly that: a reproducible, replayable evidence chain naming the operator behind a rotating egress. The per-/128 logs and lookups supply the per-NF forensic trail, keyed to a registry-anchored address rather than a mutable field in your own database. The SCAS logging requirement (TS 33.117, under GSMA SECAM) is served the same way: anchor each security-event log line to a per-NF /128 so it is unambiguously one NF's, and unforgeable after the fact.

# On the 72h clock: pull one NF's per-party trail, and who enumerated it, over the window
CALL whisper.agents({op:'logs',    args:{agent:'2a04:2a01:5e0::a3f', kind:'conn', from:'-72h'}})
CALL whisper.agents({op:'lookups', args:{agent:'2a04:2a01:5e0::a3f', window:'72h'}})

# Name the operator behind a suspect egress: attribution survives IP rotation
curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \
  --data-urlencode "q=CALL whisper.identify('203.0.113.7')"

3 · Anti-lateral-movement micro-segmentation (NSA/CISA ESF, CISA ZTMM)

The 5G SBA is a flat, all-IP, HTTP/2 mesh; when reachability at the NRF equals authorization, a single compromised NF can enumerate and reach the rest of the core. The NSA/CISA Enduring Security Framework guidance for 5G cloud infrastructure (Parts II and III) presses on exactly this: prevent lateral movement and securely isolate network resources. A per-NF /128 with default-deny egress governance is a network-layer micro-perimeter that does that: each NF may reach only its legitimate SBI peers, and nothing else, enforced by source-bound egress rather than by hoping the mesh policy holds. It advances the CISA Zero-Trust Maturity Model (v2) Identity and Visibility & Analytics pillars, and the NIST 800-207 posture O-RAN WG11 also benchmarks to.

# Default-deny egress for one NF: allow only its legitimate SBI peers, block the rest
CALL whisper.agents({op:'policy',   args:{agent:'2a04:2a01:5e0::a3f', default:'deny',
        allow:['nrf.sbi.example-mno', 'udm.sbi.example-mno']}})
CALL whisper.agents({op:'firewall', args:{agent:'2a04:2a01:5e0::a3f', deny:{cidr:'::/0', port:0}}})
CALL whisper.agents({op:'budget',   args:{agent:'2a04:2a01:5e0::a3f', cap:'50GB/day'}})
# -> the NF can talk to its allow-list and nowhere else; a spike trips the budget kill-switch.

4 · Verifiable peer identity at N32 / roaming (GSMA FS.36)

The SEPP is the mandatory PLMN-border gateway; all inter-PLMN SBI crosses N32 between two SEPPs, and where IPX providers mediate, N32-f messages are protected by PRINS (application-layer JWE+JWS over whitelisted JSON) rather than direct peer TLS. Trust is transitive through the SEPP and the IPX hubs: the originating NF deep in a peer network is not independently verifiable by the home operator, and GSMA FS.36 names the N32-c spoofing vector as a live concern. A DNSSEC/DANE-anchored identity per NF or SEPP lets the home operator verify a peer against a public anchor: resolve the peer's /128, pull its DANE pin, confirm it, instead of trusting the SEPP's assertion or the IPX's forwarding. Per-message attribution then names which PLMN/SEPP an event came from. This complements PRINS/TLS on N32-f; it never replaces the SEPP.

And the rest of the DIRECT lane: access control, logging, zero-trust

Downstream of the four, the same primitives land on several more controls as concrete, additive evidence, never as the whole standard:

• NIS2 Art.21(2)(i) access control & (2)(j) MFA / continuous authentication. A per-NF /128 is machine-level least-privilege at the cloud boundary; a DANE-verifiable identity plus one-call revoke is a continuously-checkable credential you can pull instantly. Evidentiary, one measurable input to the Art.21 posture.
• SCAS TS 33.117 logging. The SECAM assurance baseline requires security-event logging on the NF; anchoring those logs to a per-NF /128 makes each line unambiguously attributable: the differentiator, not the certification (see DO-NOT-CLAIM).
• CISA ZTMM v2 / NIST 800-207. The Identity pillar wants continuously-authenticated identity; the Visibility & Analytics pillar wants the record. DANE/DNSSEC identity, attribution and revoke advance both, and align with the same zero-trust posture O-RAN WG11 benchmarks to.

COMPLEMENTARY: we sit alongside, we don't replace the mandated controls

Several frameworks mandate the operator's own mTLS, OAuth2 or certificate. Whisper does not, and must not claim to, satisfy or replace those. It complements them: it keeps the good property they already have (a cert-bound, key-derived identity), adds the two they lack at the boundaries (public verifiability and DNS-TTL cross-operator revocation), and where a certificate is in play it can DANE-pin that exact certificate to DNSSEC to cut single-CA trust risk.

• TS 33.501 §13: mTLS on the SBI. Mutual TLS between NFs is mandatory and primary. Whisper adds an out-of-band DANE pin of the same certificate, a mis-issuance / rogue-CA defense at the trust boundaries, and never stands between two NFs in the handshake.
• TS 33.501 §13: OAuth2 / NRF authorization. Independent of the token layer; Whisper hardens the DNS under NF/NRF discovery so a valid token can't be redirected to a spoofed issuer. It issues no tokens and replaces no scope check.
• TS 33.310 §6.1.3c: the NF certificate. The certificate carrying urn:uuid:<nfInstanceId> stays exactly where it is, signed by the operator CA. Whisper projects that same identity (same UUID, from the NF's existing key) into a routable address, reverse-DNS, RDAP and the attribution graph. It never issues or cross-signs the NF cert.
• EU 5G Toolbox TM02 / TM03 / TM04. TM02 is "ensure the application of security measures," including turning on optional controls; DANE-pinned NF resolution is a concrete TM02 move. A vendor-neutral, publicly-verifiable identity also supports the supplier-diversity and hardening intents of TM03/TM04. Additive to the Toolbox, not a substitute for it.
• EU CRA Annex I. The Cyber Resilience Act's essential requirements include identity/access management and logging; Whisper is an embeddable feature that supports those. It is explicitly not a route to CRA conformity, and it does nothing for the SBOM requirement. See the caveats.
• O-RAN WG11: Zero-Trust Architecture. WG11's 2025 security work mandates mTLS 1.2+, OAuth2 and automated CMPv2 cert management on the non-fronthaul interfaces, and runs a ZTA program whose first pillar is Identity, benchmarked to the CISA ZTMM. In a multi-vendor RAN (O-RU/O-DU/O-CU/RIC/xApps from different suppliers), a vendor-neutral /128 per component, with DANE and attribution, augments that Identity pillar without every vendor chaining to one private CA. It complements WG11; it is not an O-RAN conformance claim.

DO-NOT-CLAIM: what we do NOT claim

The most useful rows on a compliance page are often the ones a vendor omits. These exist, they matter, and Whisper is honestly the wrong tool for them. We state them plainly so nobody plans against an over-claim:

• NOT a GSMA NESAS / SCAS certification control or shortcut. NESAS (FS.13) and the SCAS specifications under SECAM certify NF equipment and vendor processes. Whisper does not help you pass SCAS or NESAS; it is not a certification control. Its value to a vendor is a differentiating verifiable-identity-and-attribution feature beyond the certified baseline, and cryptographic PSIRT attribution to the exact NF instance. (Note the deliberate split from the DIRECT lane: the SCAS TS 33.117 logging requirement is supported by anchoring logs to a /128; the SCAS/NESAS certification is not.)
• NOT a mapping for FCC rip-and-replace / the Covered List. That is a supply-chain provenance-and-removal program: remove and replace untrusted-supplier equipment. Attribution can inventory which vendors are live on your network (visibility), but that is a different class of problem; we make no rip-and-replace claim.
• NEVER a replacement for the mandated mTLS / OAuth2. TS 33.501's mutual TLS and OAuth2 authorization are the primary controls and stay primary. Whisper is a second, independent DNS-anchored layer; it hardens what those leave thin at the boundaries. It does not stand in for them.
• NOT supply-chain assurance. Attribution ≠ supply-chain assurance. NIS2 Art.21(2)(d) supply-chain security is served, at most, by visibility into live vendors, not by an identity layer.

Two caveats we state up front

Buyer trust is built by naming the limits before the sales call does:

• DANE/DNSSEC on the SBA is operator-chosen defense-in-depth, strongest at the trust boundaries. It earns its keep where independent verification actually matters: NF/NRF discovery and the DNS name layer, the N32/roaming edge, the NEF northbound exposure, and management interfaces. It is not aimed at the deep intra-SBI mesh, where mTLS and the NRF already bind NF-to-NF tightly and there is little for a second layer to add. We position it as a boundary control, not an everywhere control.
• Revocation is at the identity / network / egress layer: an additional kill-switch, not operator-cert revocation. One revoke tears down the /128, its DANE pin and its egress authorization worldwide at DNS-TTL speed, faster than a private CRL or OCSP, and it crosses operator boundaries where those do not. It does not revoke the operator's TLS certificate; that remains the operator CA's job. Sell it as the fast, cross-operator kill-switch the mandated PKI does not give you, alongside (never instead of) CRL/OCSP.

Nothing issued in the dark: the transparency-log audit trail

Every identity mint and every revocation lands in a public, append-only Merkle transparency log (RFC 6962 tlog-tiles), with Ed25519-signed C2SP checkpoints, each root anchored to Bitcoin via OpenTimestamps. That gives a regulated operator something a database row cannot: a non-repudiable answer to "when was this NF identity issued, and when was it revoked", provably not back-dated, provably in order, which is exactly the evidence an NIS2 incident report or a PSIRT disclosure timeline needs to stand on.

# An NF identity's ordered lifecycle: issuance, any rotations, revocation, keyless
curl -s https://whisper.online/ip/2a04:2a01:5e0::a3f/transparency | jq

# The signed log checkpoint + its Bitcoin anchor: the tamper-evidence root
curl -s https://whisper.online/checkpoint
# -> a C2SP signed note; the root is OpenTimestamps-anchored to Bitcoin

Evidence you can hand an auditor

The point of every primitive above is that the auditor (or a roaming partner, or a regulator) does not have to trust Whisper. Each artifact is reproducible from the internet's own records with stock tools: the same --trustless walk any resolver could run. A per-control evidence bundle for a NIS2 review or a vendor RFP looks like this, and every line is checkable without an account:

# IDENTITY (TS 33.310 / SCAS 33.117-adjacent): the NF identity is genuine and current, to the IANA root
whisper verify --trustless 2a04:2a01:5e0::a3f
✓ DNSSEC chain valid to the IANA root   ✓ DANE-EE (TLSA 3 1 1) matches the NF cert key
✓ RDAP: registered under AS219419 · 2a04:2a01::/32   identity: VERIFIED, our API never trusted

# MONITORING (NIS2 Art.21(2)(b) / SCAS logging): the per-NF record and who enumerated it, on the 72h clock
CALL whisper.agents({op:'logs',    args:{agent:'2a04:2a01:5e0::a3f', kind:'conn', from:'-72h'}})
CALL whisper.agents({op:'lookups', args:{agent:'2a04:2a01:5e0::a3f', window:'72h'}})

# CONTAIN + NON-REPUDIATION (NIS2 Art.23): the eviction, provable, timestamped, cross-operator
CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:5e0::a3f'}})
curl -s https://whisper.online/ip/2a04:2a01:5e0::a3f/transparency   # the timestamped lifecycle leaf

And because an NF's telemetry or an interconnect record can be bound to (and signed under) its forge-proof /128, a roaming partner, an IPX and a regulator can all trust the record came from the real NF, which is the non-repudiation those reporting and assurance regimes ultimately want.

SIEM & threat-intel export

The evidence above is pullable now via op:logs, op:lookups and the graph API, and it exports to Splunk today as signed, replayable JSON mapped to CEF / ECS fields. Broader connectors are on the roadmap, labelled honestly so nobody plans against vapour:

Until the roadmap items land, the same records are already reachable. The exports are a convenience layer over evidence you can pull today.

What this is, and is not

Whisper anchors one boundary: the cloud/IP interface between a network function (or a SEPP, or a CAMARA/NEF consumer) and the rest of the network. It is deliberate about what it does not touch.

• It is not your NRF, your operator PKI, your SEPP or your CSMS: it is the identity-and-attribution layer those systems consume. It complements them; it does not replace them.
• It does not sit inside the SBI mTLS handshake, the O-RAN air interface / Open Fronthaul, the SIM/eSIM 5G-AKA subscriber authentication (SUPI/SUCI), or the SS7/Diameter/GTP signaling planes. Those keep their own security; a Whisper DANE-anchored identity complements them at the network layer without cross-signing. Whisper does no signaling firewalling and no GTP/SCTP packet inspection; those stay with the incumbents.
• These platform mappings are proposed, not vendor-endorsed, and no operator is named as a breach victim. The exposure classes on this page are drawn from public research and advisories at the class level only. Nation-state campaigns that reach management planes and lawful-intercept systems (a well-documented, unsolved class) show that the attribution-and-eviction problem is real; we never claim an identity layer alone would have prevented them.

Everything described as working is checkable, today, with dig, curl and one control-plane call. Everything on the roadmap is labelled as such. That is the whole contract of this page.

Next

• NF identity: how the NF-derived /128 is computed from the key an NF already holds, and why the nfInstanceId is the natural domain separator.
• NF-impersonation cure: the same identity, applied to the rogue-NRF / OAuth2-optional impersonation problem at the SBI.
• Verify · attribute · govern: runnable recipes that generate exactly the artifacts this page maps to a control.