telecom.whisper.online · for operator security teams

mTLS proves the NF at the handshake. It says nothing about the DNS, the route, or the log.

Your SBA is mutually-authenticated and your NRF issues OAuth2 tokens — inside one operator, that binds tightly. But NF discovery still addresses over DNS, OAuth2 authorization at the NRF is optional by spec, and every cert chain terminates at your private CA — unverifiable to a roaming partner, an IPX, or a regulator. Spoof the DNS to a rogue NRF, forge an issuer URL, or speak as an NF you pulled from the NRF, and no counterparty can tell. The identity is real; the anchor is invisible outside your walls.

We give the NF a public anchor. A routable, DNSSEC-signed /128 derived from the NF's own SBI key and named by the urn:uuid:<nfInstanceId> it already carries, DANE-pinned to the very cert it presents — verifiable by anyone with dig, and revocable worldwide in one call. Prove the NF at the DNS, the route and the log — and close the rogue-NRF gap 33.501 leaves open.

Secure your core → See the four claims ↓

whisper verify --trustless — anchored at the IANA DNS root. Our own API is not in the trust path.

optional OAuth2 authorization at the 5G NRF is optional by spec (TS 33.501 §13) — reachability ≈ authorization

$38.95B telecom fraud in 2023 (≈2.5% of revenue); $6.23B of it IRSF, riding interconnect trust (CFCA)

~70% of operators still lack the cloud-native capability SEPP needs (Heavy Reading, 2025)

Splunk, Microsoft Sentinel & OpenCTI SIEM connectors ship today

fail-open anchored at the IANA root — never in your SBI's critical path

on-prem the graph & per-/128 logs stay in your jurisdiction — NIS2-ready

Which desk is this?

Four ways in. One primitive underneath all of them.

Whichever chair you sit in, the ask is the same at the network layer: a publicly verifiable identity for the thing on the wire, durable attribution when the egress rotates, and a kill-switch that crosses operator boundaries. Here is how it reads from each desk.

A · MNO security architecture / core-NF SOC

You run the SBA and you carry the incident

NF · SBI · NRF · SEPP · N32 · mTLS · OAuth2 token · SCAS · lateral movement · fail-open · attribution

Trigger: NIS2 enforcement, a core-security incident, or a 5G SA rollout. Lead: mTLS proves the NF at the handshake; we prove it at the DNS, the route and the log — plus a one-call kill-switch. Close the DNS-spoofing / rogue-NRF gap 33.501 leaves open, and turn every on-wire action into signed, replayable attribution for the report.

B · Private-5G / enterprise / neutral-host

You want zero-trust without standing up a carrier PKI

private 5G · CBRS · zero trust · microsegmentation · workload identity · SASE · egress control

Trigger: a campus / neutral-host build, a customer security questionnaire, OT segmentation, or CRA on procured gear. Lead: per-NF identity and egress governance without running an operator CA — one call to provision, one to revoke. Zero-trust the way your IT team already thinks: default-deny per workload, addressed by name.

C · 5G-core / NF-vendor PSIRT

You are scored in the operator's RFP

SCAS · NESAS · TS 33.117 / 33.51x · secure-by-design · SBOM · PSIRT · CVD

Trigger: a NESAS cert cycle, an operator RFP that scores security, a CRA deadline, or a CVE. Lead (honestly — this is not a NESAS shortcut): an RFP-differentiating verifiable-identity + attribution feature beyond the certified SCAS baseline. Cryptographic PSIRT attribution to the exact NF instance, and support for the CRA identity/access + logging you already build.

D · Roaming / interconnect security

Your security is your weakest roaming partner

SEPP · N32-c / N32-f · PRINS · IPX / GRX · HPMN / VPMN · PLMN · FS.36

Trigger: a 5G SA roaming launch, an interconnect fraud/spoofing incident, GSMA conformance, or a new IPX peering. Lead: verifiable, DANE-pinned peer identity at the N32 border — harden the N32-c spoofing FS.36 names, attribute which PLMN/SEPP an event came from, and revoke a compromised interconnect identity in one call instead of a slow, manual de-peer.

Different triggers, different vocabulary — but every one of them lands on the same four claims, and each of those claims survives a hostile review.

The four defensible claims

We only make claims a red-teamer and an auditor both let stand.

Not a wall of framework logos — four claims, each traced to a named clause, each hardening a boundary the 5G stack leaves soft. Every one of them is additive to your mandated mTLS + OAuth2 and your operator PKI. If a claim didn't survive review, it isn't here.

Claim 1 · the strongest — the DNS under discovery is unsigned

3GPP binds the NF's identity into the certificate — TS 33.310 §6.1.3c mandates a SAN URI-ID = urn:uuid:<nfInstanceId>. But NF discovery and addressing ride ordinary DNS, and 3GPP mandates mTLS + OAuth2 without mandating DNSSEC/DANE on that name layer. Spoof the resolution and you redirect an NF to a rogue NRF, or forge a token-issuer URL, and every downstream check passes.

What we add. A DNSSEC-signed zone for your NF/NRF names plus a DANE-EE (TLSA 3 1 1) pin on the same certificate the NF already presents. That is a cryptographic, hijack-resistant name → address → expected-cert binding that mTLS alone does not cover — the least-contestable claim we make. Maps to TS 33.501 §13 · TS 33.310 §6.1.3c · strength ●●●

"3GPP already mandates mutual TLS on the SBI. Why isn't the cert enough?"

Because the cert is signed by your private CA and addressed over unsigned DNS. mTLS proves two endpoints negotiated a key; it says nothing about whether the name you resolved is the NF you meant, and no roaming partner or regulator can chain your CA to a public anchor. We DANE-pin the exact cert the NF presents into the DNSSEC root — the binding becomes hijack-resistant and third-party verifiable, with your mTLS untouched underneath.

Claim 2 · attribution for incident handling & reporting

When an NF misbehaves — or a rogue one speaks on your SBI — the clock starts: NIS2 Article 23 wants an early warning in 24 hours, a notification in 72, a final report in a month. But the attacker's egress rotates across clouds and a small IPX, so all your SOC has logged is a meaningless last IP.

What we add. A live internet-infrastructure graph, 7.44B nodes and 39.3B relationships of fused BGP, DNS, WHOIS, TLS, hosting and threat intelligence, answering in under 300 ms, that fingerprints the operator, not the IP: shared ASN/hosting/certificate lineage collapses the cloud rotation, and a JA4/JA3 client fingerprint travels with the tooling to collapse a hosted swarm. Every answer is a reproducible, replayable evidence chain, and each NF's own SBI activity is logged against its /128, ready-made SCAS TS 33.117 log material and NIS2 forensics. Maps to NIS2 Art.21(2)(b) & Art.23 · SCAS TS 33.117 · strength ●●●

Claim 3 · anti-lateral-movement micro-segmentation

The flat, all-IP, HTTP/2 SBA mesh inherits the whole web/API threat model. OAuth2 authorization at the NRF is optional by spec, so in too many cores reachability approximates authorization: any NF that can reach the NRF can enumerate every NF, pull a profile, and move laterally.

What we add. A per-NF /128 micro-perimeter with default-deny egress governance — op:firewall allow/deny by host, CIDR or port; op:budget caps a compromised NF's traffic; op:revoke cuts it off worldwide. An NF talks only to the names it should, and a foothold on one NF does not become a foothold on the mesh. Maps to NSA/CISA ESF 5G Cloud Pt II–III · CISA ZTMM Identity pillar · NIST 800-207 · strength ●●●

Claim 4 · verifiable peer identity at the N32 border

Every inter-PLMN message crosses N32 between two SEPPs, and trust is transitive and opaque: through the peer's SEPP, and — with PRINS — through semi-trusted IPX hubs that can read and modify whitelisted JSON. The originating NF deep in the peer network is not independently verifiable by the home operator. It is the weakest point of the modern stack.

What we add. A DNSSEC/DANE-anchored identity per NF and per SEPP lets the home operator verify a peer against a public anchor — "verify the address + the DANE pin" instead of "trust the SEPP's assertion" — independent of the peer's private CA and any IPX, hardening the N32-c spoofing vector GSMA FS.36 names. Revoke a compromised interconnect identity in one call. Maps to GSMA FS.36 · TS 29.573 (N32) · strength ●●○

"IEEE-grade PKI already runs the SBA. What can a DNS layer possibly add at the roaming border?"

A verification you can do without the peer's CA. Cross-operator trust today means bilaterally cross-certifying every MNO's private root — an N² PKI exchange, mediated by IPX. A DANE pin anchored in the public DNSSEC root collapses that to a resolve-and-check: the home operator confirms the peer NF's address maps to the expected key with no cross-certification, and a revoke propagates at cache-TTL rather than one CRL per operator.

Four claims, one address. Below the boundary these ride, the derivation is the cure — here is how a name you already have becomes a name anyone can verify.

Your NF already has a name — we make it public

The address is the NF — derived from the key it already holds.

Every 5G NF registers a NFProfile with the NRF (TS 29.510): an nfInstanceId (a UUID), an nfType, and at least one of fqdn / ipv4Addresses / ipv6Addresses. A resolvable identity already exists — it is just trapped in your private NRF and private PKI.

Derive a routable IPv6 /128 out of 2a04:2a01::/32 (announced by AS219419) from the NF's existing SBI key, with the nfInstanceId as the domain separator (pass it as device_id). The private key never leaves the NF; the address is a one-way function of its public half and that UUID. Drop the /128 straight into NFProfile.ipv6Addresses — no NRF API change — sign the ip6.arpa reverse zone, and pin the same certificate the NF already presents with DANE-EE. The operator-private identity becomes globally, third-party verifiable: a roaming partner or a regulator resolves the /128, pulls the DANE pin, and confirms "this address is NF X" without your CA. Revoke = pull the signed record.

The nfInstanceId already binds the NF's key to its identity inside the cert — but only your private CA can vouch for it. Whisper anchors the same identity in the public DNSSEC root and the routing table, and gives it a cross-operator off-switch.

Shipped & live today. Derive a /128 from your NF's public key with its nfInstanceId passed as device_id — deterministic (same key + id → the same /128), tenant-bound and fleet-unlinkable (the same key under two tenants yields two unrelated /128s, so no one can correlate an NF across operators), enumeration-resistant (the nfInstanceId alone yields nothing without the key), and revocable at DNS-TTL. A first-class typed --nf-instance-id argument is on the roadmap; the generic device_id door is live now.

It attaches to what you already ship — it does not replace it. Whisper is the publicly verifiable, DNSSEC/DANE-anchored layer on top of the anchors you already trust — your operator CA and CMPv2 enrolment, the SBA cert profile, OAuth2 at the NRF, the SEPP at the border. No bespoke trust store to push to every NF, and a cross-operator revoke at DNS-TTL instead of a CRL that never crosses the boundary. You can even DANE-pin the cert your NRF and SEPP already present to cut single-CA trust risk at the boundary.

The border — and the surface no one else has

Verify the peer at N32. See who's mapping your core. Prove nothing was issued in the dark.

An identity you can prove is also an identity you can watch and govern. Because every NF's name resolves through Whisper's own authoritative DNS and RDAP, and every mint and revoke lands in a public log, three surfaces open that a private NRF never gave you.

At the roaming border, "trust the SEPP" becomes "resolve and check the DANE pin." The home operator verifies the peer against the public root — the FS.36 N32-c spoofing vector loses its opacity, and a compromised interconnect identity is one revoke away.

Who checked this NF is a query

op:lookups returns who resolved or RDAP-queried an NF's identity — an early warning that someone is mapping your core before the impersonation, the rogue-NRF reconnaissance tripwire a private NRF never surfaced. Shipped.

Govern what each NF may reach

A graph-first resolver and source-bound egress enforce default-deny per NF — op:firewall by host/CIDR/port, op:budget to cap it, op:revoke to cut it off worldwide. The per-NF micro-perimeter of Claim 3, as a control plane. Shipped.

Nothing issued in the dark

Every identity mint and every revoke lands in a public, append-only RFC 6962 Merkle log, Ed25519-signed and anchored to Bitcoin via OpenTimestamps — an auditable NIS2 issuance trail. Honest status: tamper-evident today, independent witnessing is the next step.

The same address-is-identity primitive that governs a compromised NF also governs the AI agents your NOC and OSS/BSS are about to run — per-agent /128, per-agent logs, default-deny egress, one revoke. From day one.

Additive by construction

We DANE-pin. We never replace.

This is a second, independent, DNS-anchored layer — strongest at the trust boundaries (NF discovery/DNS, N32/roaming, NEF exposure, management), not deep intra-SBI where mTLS and the NRF already bind tightly. Everything below stays yours; we harden the name and the route beneath it.

3GPP mTLS + OAuth2 / NRF

Mandatory and primary. We do not touch the handshake or the token exchange — we pin the cert the NF already presents into DNSSEC, and harden the DNS under NF/NRF discovery so a token can't be redirected to a spoofed issuer.

Operator PKI + SEPP

Your CA, CMPv2 enrolment and N32/PRINS topology-hiding keep running. We add a public anchor for the same identity so a peer or a regulator can verify it without cross-certifying your private root.

EU 5G Toolbox TM02 · ENISA controls

TM02 is "turn on optional security controls." A DANE-pinned NF resolution is a TM02 move — a concrete control you can point at, with TM03/TM04 supported alongside.

EU CRA · O-RAN WG11 ZTA

For a vendor, we support the CRA Annex I identity/access + logging you already build (not a conformity route). For O-RAN, a vendor-neutral public /128 per NF serves the WG11 Zero-Trust Identity pillar without every supplier chaining to one private CA.

Availability-safe — fail-open by construction. If your discovery or border check consults the DANE/verify path, that plane is built to fail open: a Whisper outage never drops an NF's SBI traffic — the check degrades to the anchors you already ship, and connectivity is preserved. Anycast on AS219419, no single node in the path, no chatty third-party call on the hot path. Conservative in what we emit, liberal in what we accept — an NF is never denied because we were unreachable.

Speaks your compliance language

Every capability lands on a clause — and produces an artifact you can file.

All additive to your mandated 3GPP mTLS + OAuth2, your operator PKI, and your SEPP. Strength is stated honestly: ●●● a claim that survives a hostile review, ●●○ a solid defense-in-depth fit, ●○○ visibility only.

Defensible claim	Standard / clause	Evidence artifact	Strength
Close the DNS-spoofing / rogue-NRF / forged-issuer gap	3GPP TS 33.501 §13 · TS 33.310 §6.1.3c (SAN `urn:uuid`)	DNSSEC-signed NF/NRF zone · DANE-EE `3 1 1` pin on the presented cert	●●●
Attribution for incident handling & reporting	EU NIS2 Art.21(2)(b) & Art.23 (24h/72h/1-mo) · SCAS TS 33.117 logging	Reproducible, replayable evidence chain · per-/128 SBI logs	●●●
Anti-lateral-movement micro-segmentation	NSA/CISA ESF 5G Cloud Pt II–III · CISA ZTMM Identity · NIST 800-207	Per-NF /128 micro-perimeter · default-deny egress policy	●●●
Verifiable peer identity at the N32 border	GSMA FS.36 · TS 29.573 (N32-c/N32-f)	DANE-pinned peer/SEPP identity · one-call revoke	●●○
Project the NF cert identity into routing / reverse-DNS / RDAP	TS 33.310 (nfInstanceId ↔ key ↔ endpoint)	/128 from the NF's existing key · RDAP object · `ip6.arpa`	●●○
Turn on an optional 5G security control	EU 5G Toolbox TM02 (ENISA) · TM03/TM04	DANE-pinned NF resolution — a concrete TM02 control	●●○
Continuously-authenticated identity + fast revoke	CISA ZTMM Identity/Visibility · NIS2 21(2)(j)	DANE-verifiable identity · DNS-TTL revoke log	●●○
Embeddable identity/access + logging feature (vendors)	EU CRA Annex I — identity/access, logging	Supports what you already build — not a conformity route	●●○
Inventory which vendors are live on the wire	FCC Covered List (context only)	Attribution feed — not a supply-chain / removal mapping	●○○

Findings map onto CEF and ECS fields today; STIX 2.1 over TAXII and per-sector machine-readable export are on the roadmap. The Splunk, Microsoft Sentinel and OpenCTI connectors ship today.

Three planes on one primitive — and all three exit into the stack you already run, not a new silo. It rides your DNS and IPv6 and adds no inline SBI chokepoint.

What we do not claim

The honest boundary — stated plainly, because a telecom buyer checks.

Overclaiming loses the room. Here is exactly where Whisper stops, so the four claims above are trusted precisely because these five are ruled out.

Not a NESAS / SCAS shortcut

DANE/DNSSEC on the SBA is not a certification control and will not help you pass SCAS or a NESAS audit. The value is a defense-in-depth differentiator and a PSIRT attribution tool — beyond the certified baseline, never a substitute for it.

Nothing for FCC rip-and-replace

The Covered List is supply-chain provenance and removal — a different class. Attribution can inventory which vendors are live on the wire, but that is visibility, not a compliance mapping, and never assurance about a vendor's supply chain.

Never replaces mTLS or OAuth2 / NRF

Those are mandatory and primary. This is a second, independent, DNS-anchored layer that hardens the name→address→cert binding underneath them — strongest at trust boundaries, not deep intra-SBI where the NRF already binds tightly. We do not touch the handshake.

Revocation is at the identity / network layer

One call tears down the /128 + PTR + DANE pin + egress authorization worldwide at DNS-TTL — faster than a cross-operator CRL/OCSP — but it does not revoke the operator's TLS certificate; that stays your CA's job. It is an additional kill-switch, not a replacement.

And an identity layer alone does not stop everything. Router/edge implants, stolen management credentials, and nation-state persistence below the identity layer are not stopped by verifiable identity — the class of interconnect intrusion publicly reported to have reached lawful-intercept systems across dozens of carriers is cited here only to show that cross-operator attribution and eviction remain unsolved, never as something we claim we would have prevented. That honesty is the point: we bite the impersonation and the unattributed-persistence stages hardest, and we say so.

Prove it in 60 seconds · no account

Don't take our word for it — our API isn't in the trust path.

Two tiers, by design. No key: anyone on your team can verify an NF's identity, resolve it, and back-trace a suspicious NRF — trustless, anchored at the IANA root. Your key: bind an NF to the nfInstanceId it carries, see who's mapping your core, govern its egress, and revoke it worldwide.

verify an NF — keyless · attribute a rogue NRF — graph API

# keyless — re-derive and verify any NF's identity, trustless
$ whisper verify --trustless 2a04:2a01:5e0::a3f
  ✓ DNSSEC chain valid to the IANA root
  ✓ DANE-EE (TLSA 3 1 1) leaf matches the NF's SBI certificate
  ✓ RDAP: registered under AS219419 · 2a04:2a01::/32
  identity: VERIFIED — same urn:uuid:<nfInstanceId>, no operator CA needed

# the address is the NF — reverse DNS names it
$ dig -x 2a04:2a01:5e0::a3f +short
  amf01.nf.mnc015.mcc234.5gc.example-mno.whisper.online.

# who really operates a suspicious NRF/host — the graph API, a CALL whisper.identify()
$ curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \
    -H 'content-type: application/json' -d '{"query":"CALL whisper.identify(\"203.0.113.7\")"}'
  operator:  <fingerprinted> · seen across AWS / GCP / a small IPX
  hosted rotation collapsed by JA4: same tooling, 37 exit IPs → 1 operator

provision, watch & govern — with your key

# bind an NF to the instance id it already carries — device_id = nfInstanceId
$ export WHISPER_API_KEY=whisper_live_xxx
$ curl -s https://graph.whisper.security/api/query -H "X-API-Key: $WHISPER_API_KEY" --data-urlencode "q=CALL whisper.agents({op:'connect', args:{tier:'wireguard',
       identity_public_key:'<base64 SPKI of the NF SBI key>',
       device_id:'3f2504e0-4f89-11d3-9a0c-0305e82c3301'}})"   # device_id = nfInstanceId
  → identity 2a04:2a01:5e0::a3f   DNSSEC + DANE live · drop into NFProfile.ipv6Addresses
$ whisper logs 2a04:2a01:5e0::a3f                     # this NF's own SBI egress, per-/128
$ curl -s https://whisper.online/ip/2a04:2a01:5e0::a3f/lookups   # who's mapping your core — recon tripwire
$ whisper policy set --default deny --allow nrf.5gc.example-mno.com,udm.5gc.example-mno.com
$ whisper kill --revoke 2a04:2a01:5e0::a3f            # worldwide, at DNS-TTL — the federated kill-switch

Secure your core → Compare the fit

Four defensible claims. Mapped to your standards. Additive to your stack.

Prove the NF at the DNS, the route and the log; attribute the operator when the egress rotates; micro-segment the mesh; verify the peer at N32 — additive to your mTLS/OAuth2 and operator PKI, fail-open in your path, mapped to 33.501 / NIS2 / the CISA ESF / GSMA FS.36. Keyless to try, one call to provision, one more to revoke.

Secure your core → See pricing →

Or run whisper verify --trustless right now.