# 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). > **How to read this page.** We grade every control into one of three verdicts and never blur them. **DIRECT-ADDITIVE.** Whisper produces evidence that maps to the control (as one input to your package, never the whole standard). **COMPLEMENTARY.** The framework mandates the operator's own PKI, mTLS or OAuth2; Whisper sits alongside it and can DANE-pin it, but does *not* satisfy or replace that requirement. **DO-NOT-CLAIM.** Things Whisper is honestly not: a NESAS/SCAS certificate, an FCC rip-and-replace mapping, a substitute for mandated mTLS. We list them so nobody over-claims. ## 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:`), 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: - **DIRECT-ADDITIVE.** Whisper produces the evidence, as one input to your package: TS 33.501 DNS/rogue-NRF · NIS2 Art.21/23 · NSA/CISA ESF 5G-cloud · GSMA FS.36 (N32) · SCAS TS 33.117 logging · CISA ZTMM. - **COMPLEMENTARY.** Sits alongside, DANE-pins the cert, never satisfies it: TS 33.501 mTLS + OAuth2/NRF · TS 33.310 NF cert · EU 5G Toolbox TM02 to TM04 · EU CRA Annex I · O-RAN WG11. - **DO-NOT-CLAIM.** Things Whisper is honestly not: a NESAS/SCAS certification · FCC rip-and-replace · a replacement for mandated mTLS/OAuth2. The honesty rule is the whole point of this page: a network primitive earns a verdict per control, and we mark `DIRECT-ADDITIVE`, `COMPLEMENTARY` or `DO-NOT-CLAIM` so a security architect, an auditor and a regulator all read the same thing. ## 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`. > **Shipped & live.** The NF-derived `/128`, per-`/128` logs, `op:lookups`, one-call `revoke`, egress governance (`policy`/`firewall`/`budget`), the Merkle transparency log and the attribution graph are in production. The **Splunk** connector ships. Everything grouped under *roadmap* below is labelled as such. Nothing on this page is described as working unless you can reproduce it. ### 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:`. 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:'', 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. ``` > `3f2504e0-4f89-11d3-9a0c-0305e82c3301` is a placeholder RFC 4122 UUID. No real network function or operator is implied. The `device_id` argument is generic: pass the `nfInstanceId`, an NFProfile identity, or a bare NF/SEPP serial. A first-class typed `--nf-instance-id` CLI/API flag is **on the roadmap**; provision via the control-plane call above today, which **is** live. ### 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. | Framework · control | What it asks for | Verdict | Whisper evidence (shipped) | |---|---|---|---| | **3GPP TS 33.501**: DNS-spoofing / rogue-NRF / forged token-issuer vector | A hijack-resistant name→address→expected-cert binding under NF/NRF discovery (which rides DNS) | DIRECT-ADDITIVE | DNSSEC-signed zone + DANE-EE `3 1 1` pin on the NF/NRF record, the cert the NF already presents | | **EU NIS2** Art.21(2)(b) + Art.23 | Incident handling; early-warning 24 h / notification 72 h / final report 1 month | DIRECT-ADDITIVE | Attribution graph (who/where) + per-`/128` `logs` + `lookups`, on the reporting clock | | **NSA/CISA ESF** 5G Cloud (Parts II and III) | Prevent lateral movement; securely isolate network resources | DIRECT-ADDITIVE | Per-NF `/128` micro-perimeter + default-deny `policy`/`firewall`/`budget` egress governance | | **GSMA FS.36**: N32 / SEPP | Harden the N32-c spoofing vector; verifiable peer identity at the roaming boundary | DIRECT-ADDITIVE | DANE-pinned peer/SEPP identity + per-message attribution, alongside PRINS/TLS on N32-f | | **EU NIS2** Art.21(2)(i)/(j) | Access control; MFA / continuous authentication | DIRECT-ADDITIVE | Per-NF `/128` least-privilege egress + DANE-verifiable identity + one-call `revoke` | | **SCAS TS 33.117**: logging | Security-event logging on the NF (SECAM assurance) | DIRECT-ADDITIVE | Logs anchored to a per-NF `/128`, each event unambiguously one NF's | | **CISA ZTMM v2** / NIST 800-207 | Continuously-authenticated Identity; Visibility & Analytics pillars | DIRECT-ADDITIVE | DANE/DNSSEC identity + `revoke` + attribution advance the Identity & Visibility pillars | | **3GPP TS 33.501** §13: mTLS on the SBI | Mutual TLS between every NF pair | COMPLEMENTARY | Add a DANE out-of-band pin of the same cert (mis-issuance / rogue-CA defense); never replaces mTLS | | **3GPP TS 33.501** §13: OAuth2 / NRF authz | Token-based service authorization, NRF as authorization server | COMPLEMENTARY | Independent; hardens the DNS under discovery so a token can't be aimed at a spoofed issuer | | **3GPP TS 33.310** §6.1.3c: NF cert (`urn:uuid:nfInstanceId`) | Operator-CA-signed NF certificate identity | COMPLEMENTARY | Project the SAME identity into routing + reverse-DNS + RDAP + attribution; `/128` from the NF's existing key | | **EU 5G Toolbox** TM02 / TM03 / TM04 | Apply / strengthen optional security controls; supplier diversity | COMPLEMENTARY | DANE-pinned NF resolution is a concrete TM02 move; a vendor-neutral identity supports TM03/TM04 | | **EU CRA** Annex I: identity/access + logging | Essential cybersecurity requirements for products with digital elements | COMPLEMENTARY ¹ | Supports as an embeddable identity/logging feature, *not* a CRA conformity route; nothing for SBOM | | **O-RAN WG11**: ZTA on O1/O2/A1/E2 | mTLS + OAuth2 + CMPv2 + a Zero-Trust program whose first pillar is Identity | COMPLEMENTARY | Per-component `/128` + DANE + attribution augment the ZTA Identity pillar across vendors | | **GSMA NESAS / SCAS** (FS.13, SECAM) | Product- & process-security certification of NF equipment | DO-NOT-CLAIM | Not a certification control or shortcut; it does not help you pass SCAS/NESAS (a differentiator + PSIRT tool) | | **FCC** rip-and-replace / Covered List | Remove & replace untrusted-supplier equipment | DO-NOT-CLAIM | A supply-chain provenance/removal program, not an identity mapping | | **TS 33.501** mandated mTLS + OAuth2 | The primary, mandatory SBA security controls | DO-NOT-CLAIM | Whisper is a second, independent DNS-anchored layer; it never replaces the mandated controls | | **EU NIS2** Art.21(2)(d) | Supply-chain security / assurance of suppliers | DO-NOT-CLAIM | Attribution can *inventory* live vendors (visibility); it is not supply-chain assurance | ¹ 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:`, 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. *Figure. The gap 33.501 leaves open is a layer below mTLS: the name→address resolution. DNSSEC makes the answer forgery-evident to the IANA root, and DANE pins the exact certificate the NF already presents, so a rogue NRF or a forged issuer is rejected before the consumer ever trusts a token.* ### 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. *Figure. The home operator's trust in a roaming peer is only as good as the weakest IPX in the path. A DANE-pinned peer identity lets the home SEPP confirm the originating NF against the public DNSSEC root directly: a second, independent check that hardens the N32-c spoofing vector FS.36 names, alongside PRINS and TLS.* ### 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](/docs/dane) 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:` 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. > Why this whole group is COMPLEMENTARY and not DIRECT: these frameworks name the operator's own PKI, mTLS and OAuth2 as the primary, mandatory controls. Whisper is a *second, independent, DNS-anchored* layer that hardens the boundaries those controls leave thin: the name layer, the roaming edge, the cross-operator gap. It complements the mandate; it is never the mandated control. ## 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](/docs/transparency) (RFC 6962 `tlog-tiles`), with Ed25519-signed C2SP checkpoints, each root anchored to Bitcoin via [OpenTimestamps](/docs/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 ``` > **Honest status.** The log is tamper-evident, Ed25519-signed and Bitcoin-anchored *today*, but it is **not yet independently witnessed** (our two authoritative nodes co-signing is availability, not independence). It already speaks the C2SP `tlog-witness` protocol, so an external witness can co-sign; until one does, treat the guarantee as tamper-*evident*, not third-party-attested. It is also GDPR-compatible: leaves are salted opaque commitments with selective disclosure, so erasing the salt renders a leaf's meaning unrecoverable while the proofs stay valid. ## 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](/docs/sign-outputs)) 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: | Destination | Status | |---|---| | Splunk (signed JSON → CEF / ECS) | **Shipped** | | Microsoft Sentinel connector | **Shipped** | | OpenCTI | **Shipped** | | STIX 2.1 / TAXII feed | Roadmap | | Telecom-ISAC / GSMA T-ISAC machine-readable JSON export | Roadmap | 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](/docs/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](/docs/nf-impersonation-cure): the same identity, applied to the rogue-NRF / OAuth2-optional impersonation problem at the SBI. - [Verify · attribute · govern](/docs/telecom-recipes): runnable recipes that generate exactly the artifacts this page maps to a control.