Platform integrations

Whisper sits beside the 5G core you already run and anchors exactly one thing: a routable, verifiable identity at the SBI / N32 / NEF IP boundary. That's the layer where an impersonated network function or a spoofed roaming peer looks identical to the real one today, because every certificate in the chain terminates in a private CA no outsider can check.

Everything below is a proposed integration pattern (our design, not a vendor endorsement), and every one is written the same way: Whisper complements the mechanism you have; it never replaces it. We do not touch 5G-AKA in the UICC/eSIM, we do not conceal the SUPI as a SUCI, and we do not inspect SS7 / Diameter / GTP-C signalling messages on the wire. The subscriber plane, the radio air interface, and your signalling firewall are each already someone's job. Whisper's job is the network identity of whatever is talking to your control plane: an NF on the SBI, a SEPP at the roaming border, an Open Gateway API caller, an O-RAN component, expressed as an IPv6 /128 that DNSSEC, DANE and RDAP can prove and one call can revoke.

Anchor the boundary, not the subscriber plane

A 5G network carries several trust mechanisms, each correct for its own layer. The mistake is to imagine a new identity system has to displace one of them. It doesn't. Whisper is deliberately confined to the one place none of them cover: the moment a network endpoint claims to be a particular NF, SEPP, or sanctioned API consumer, and the receiver has only an OAuth2 bearer token or a certificate chained to a private operator CA to go on.

Read the last row as the whole thesis. On the SBI, TS 33.501 makes mutual TLS mandatory and the certificate is the identity anchor. TS 33.310 §6.1.3c even binds the identity into the cert, mandating a subjectAltName URI-ID of urn:uuid:<nfInstanceId>. But that certificate is signed by the operator's private CA, enrolled over CMPv2, with no public root: nothing outside the operator can validate it. Identity today is a claim that only your own PKI can check. Whisper turns it into a network fact: the source address itself, forward-confirmed in DNS, pinned in DANE, registered in RDAP.

The 5G NRF: the keystone

Every NF (AMF, SMF, UPF, PCF, UDM, AUSF, NSSF…) is an HTTP/2 + JSON microservice on the SBI, and it registers an NFProfile with the NRF (TS 29.510). That profile already carries the fields a public identity needs: an nfInstanceId (a UUID, RFC 4122), an nfType, an nfStatus, and at least one of fqdn / ipv4Addresses / ipv6Addresses. A resolvable NF identity already exists. It is just trapped inside the operator's private NRF and private PKI, verifiable only after bilateral cross-certification.

The integration is a near-literal drop-in, with no NRF API change. Derive a /128 from the NF's existing SBI key plus its nfInstanceId (passed as device_id), then publish that address as one more entry in the NFProfile's ipv6Addresses array, beside the operator's own. Because the address is DNSSEC-anchored with a DANE TLSA that pins the same certificate the NF already presents on the SBI (the one whose SAN is urn:uuid:<nfInstanceId>), a roaming partner, a regulator, or another operator can resolve the address, pull the pin, and confirm "this address is NF X" without ever touching the operator's private CA.

# The Whisper /128, published as one more entry in the NFProfile.ipv6Addresses array.
# NRF unchanged; the address is now a globally verifiable name for the same NF.
{
  "nfInstanceId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "nfType":       "SMF",
  "nfStatus":     "REGISTERED",
  "fqdn":         "smf01.5gc.mnc015.mcc234.3gppnetwork.org",
  "ipv6Addresses": [
    "2001:db8:5gc::a3f6",
    "2a04:2a01:9c0::a3f6"          // ← the Whisper /128: DNSSEC + DANE, publicly verifiable
  ]
}

Point a resolver at it and the identity confirms itself straight from the internet's own records. No NRF query, no operator PKI:

# The address is the NF: forward-confirmed reverse DNS names it.
dig -x 2a04:2a01:9c0::a3f6 +short
nf-3fa85f64.sba.<tenant>.agents.whisper.online.

# Pin the SBA certificate the NF already presents: the leaf key, in DNSSEC-signed DNS.
dig +dnssec TLSA _443._tcp.nf-3fa85f64.sba.<tenant>.agents.whisper.online
;; flags: qr rd ra ad          ← ad = DNSSEC-authenticated
;; _443._tcp....agents.whisper.online. 300 IN TLSA 3 1 1 b653a4ef...fcb82d1d

The shipped spine attaches right here. The SBA certificate (whose key is already the anchor 3GPP trusts) is the birth certificate the /128 is derived from: submit the NF's public SPKI, pass the nfInstanceId as device_id, and the NRF and its consumers can authorize a forge-proof address instead of only a portable token. The private key never leaves the NF; the derivation is deterministic and tenant-bound, and the full mechanics live on NF identity.

# The spine: derive the NF's /128 from the SBI key it already holds + its nfInstanceId.
CALL whisper.agents({op:'connect', args:{
  tier:                'wireguard',
  identity_public_key: '<base64 SPKI of the NF's SBI key>',
  device_id:           '3fa85f64-5717-4562-b3fc-2c963f66afa6'   // the nfInstanceId (urn:uuid in the cert SAN)
}}) YIELD op, ok, status, result, error
   RETURN op, ok, status, result, error

Send it with stock tools. The control plane is one HTTP endpoint; the key travels only in the header:

curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  --data @- <<'JSON'
{"query":"CALL whisper.agents({op:'connect', args:{tier:'wireguard', identity_public_key:'<base64 SPKI>', device_id:'3fa85f64-5717-4562-b3fc-2c963f66afa6'}}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error"}
JSON
{ "op":"connect", "ok":true, "status":"created",
  "result":{ "address":"2a04:2a01:9c0::a3f6",
             "fqdn":"nf-3fa85f64.sba.<tenant>.agents.whisper.online",
             "wireguard":{ /* peer, keys, allowed-ips */ } } }

SEPP & N32: verifiable peer identity at the roaming border

The SEPP is the mandatory PLMN-border gateway: all inter-PLMN SBI traffic crosses N32 between two SEPPs (TS 29.573). N32-c is the TLS handshake that negotiates policy; N32-f carries the roaming messages, protected either by direct TLS between peers or, when IPX providers mediate, by PRINS (application-layer JWE + JWS), a model in which the IPX hub is semi-trusted and may read and modify whitelisted JSON. The SEPP also performs topology hiding, rewriting the interPlmnFqdn / telescopic FQDN and stripping internal addresses.

The consequence is a chain of transitive, opaque trust: the originating NF deep in the peer network is not independently verifiable by the home operator. Your security is your weakest roaming partner, and you cannot see which partner that is. GSMA FS.36 names the N32-c spoofing vector specifically. This is the highest-leverage boundary on the whole network, and it is exactly where a public anchor helps most.

The integration gives each NF and each SEPP a DANE-pinned /128 so the home operator can cryptographically verify a peer against a public anchor, independent of the peer's private CA and of any IPX in between. Instead of "trust the SEPP's assertion," it becomes "verify the address and its DANE pin against the DNSSEC root." This hardens N32-c; it does not touch PRINS or the N32-f message protection, which stay exactly as GSMA specifies.

# The home operator confirms a roaming peer's SEPP before it trusts the border: no shared CA.
whisper verify --trustless sepp.vpmn-mcc262mnc02.<tenant>.agents.whisper.online
dnssec   pass   DNSSEC-root   AAAA, PTR and TLSA(3 1 1) all DNSSEC-validated to the IANA root
dane     pass   DNSSEC-root   served leaf SPKI-SHA256 == TLSA pin
CRYPTOGRAPHICALLY PROVEN, trust anchor: DNSSEC root (IANA) + DANE-EE

# Kill a compromised interconnect identity everywhere in one TTL, not one CRL per operator.
CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:9c0::5e00'}})

See who is probing the border, before the message lands. Because every NF and SEPP identity resolves through Whisper's own authoritative DNS and RDAP, you can ask who looked. op:'lookups' returns who has been resolving or RDAP-querying an identity. It's a reconnaissance tripwire for an attacker enumerating your NFs across the interconnect, caught in recon rather than in the post-mortem:

# who has been resolving / RDAP-querying this NF or SEPP identity, and when
CALL whisper.agents({op:'lookups', args:{agent:'2a04:2a01:9c0::5e00', window:'24h'}})

CAMARA / GSMA Open Gateway: a public anchor for the API caller and target

GSMA Open Gateway exposes network capability as developer- and agent-facing APIs: SIM-swap, number-verify, device-location, quality-on-demand, standardised through CAMARA and fronted by the NEF northbound. It is the network's new front door, and it inherits the full web-API threat model: broken object-level authorization, shadow endpoints, mis-scoped tokens. An API caller is a bearer token from anywhere; an API target is a hostname a client takes on faith.

This is the two-tier Postel shape at its cleanest. With no key, any developer or agent can verify (trustlessly, from the DNSSEC root) that the Open Gateway endpoint they are about to call really is the sanctioned target, and an aggregator can confirm a caller's network identity before honoring a request. With a key, the caller or the exposed service is itself provisioned a /128, source-bound so the request arrives from an allowlisted address a replayed token cannot forge.

# Keyless: a developer or agent confirms the Open Gateway API target before calling it.
curl https://whisper.online/verify-identity/2a04:2a01:9c0::ca3a
{"is_whisper_agent": true, "dane_ok": true, "jws_ok": true, "evidence": { … }}

# Keyed: bind an API caller's egress to its /128 and default-deny the rest.
whisper policy set --agent 2a04:2a01:9c0::ca3a \
  --default deny --allow api.opengateway.<tenant>.agents.whisper.online

O-RAN: a public /128 for every disaggregated component

An O-RAN deployment splits the RAN across suppliers: O-RU, O-DU, O-CU, the near-RT and non-RT RIC, and third-party xApps/rApps, talking over E2 (SCTP/E2AP), A1 (REST), O1 (NETCONF/YANG), O2 (REST) and the Open Fronthaul. O-RAN WG11 (Feb 2025) mandates mTLS 1.2+ everywhere off the fronthaul, OAuth2 as the common authorization, and automated certificate management over CMPv2. It also runs a Zero-Trust Architecture program whose first pillar is Identity, benchmarked to the CISA Zero-Trust Maturity Model.

Multi-vendor disaggregation multiplies the parties that must trust each other's certificates, and each still chains to a private, per-vendor or per-operator CA. A vendor-neutral, publicly verifiable /128 per O-RAN component serves the WG11 ZTA Identity pillar directly, without every vendor cross-certifying into one root. It augments the mandated mTLS / CMPv2 / OAuth2 across O1, O2 and A1 with a DANE pin any party can check, and adds per-component egress governance, the least-privilege the ZTA also asks for.

# Pin an A1 (or O1/O2) endpoint's leaf key in DNSSEC-signed DNS: no shared CA across vendors.
dig +dnssec TLSA _443._tcp.near-rt-ric.oran.<tenant>.agents.whisper.online
;; _443._tcp....agents.whisper.online. 300 IN TLSA 3 1 1 9c0de5e0...a11f0d0d

# Least-privilege per component: default-deny what an O-DU may reach, in one call.
CALL whisper.agents({op:'firewall', args:{
  agent:   '2a04:2a01:9c0::0d0',                // the O-DU's /128
  default: 'deny',
  allow:   ['near-rt-ric.oran.<tenant>.agents.whisper.online',
            'smo.oran.<tenant>.agents.whisper.online']
}})

And because each component has a forge-proof address, its telemetry and its E2/A1 policy actions can be signed under that /128, so the SMO, an operator SOC, and a vendor PSIRT can trust a measurement or a policy decision came from the real component, non-repudiably, rather than a spoofed peer in a multi-vendor mesh.

The SIEM feed: Splunk, Sentinel & OpenCTI today

Identity and attribution are only useful to a telecom SOC if they land in the tools it already runs. Whisper emits every finding as a signed JSON evidence chain: a whisper.identify attribution result, an op:'lookups' enumeration alert, an identity mint or revoke from the transparency log, so it is machine-readable enrichment for your signalling firewall and threat-intel, not another console an analyst babysits. For NIS2 Art.23 incident reporting (24h / 72h / 1 month), that cryptographic attribution accelerates the who / where forensics.

The Splunk connector is shipped today. It maps each signed finding onto CEF and ECS fields and forwards it into Splunk, so a fleet-enumeration tripwire or a rotating-egress attribution becomes a correlatable event beside your Enea / P1 / Positive Technologies signalling telemetry:

# The signed finding the Splunk connector maps to CEF / ECS and forwards.
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(\"185.12.x.x\")"}' | jq '.result.evidence'
# -> a replayable, signed evidence chain -> CEF: deviceVendor=Whisper cs1=operator …
#    (the connector emits one event per finding; the chain re-verifies offline)

The Microsoft Sentinel connector and OpenCTI threat-intelligence integration ship today, mapped onto Sentinel's connector framework and OpenCTI's knowledge graph for continuous-monitoring workflows. STIX 2.1 over TAXII export is on the roadmap, not shipped. It is listed honestly under On the roadmap below.

Shipped today vs proposed

Honesty about what runs matters more here than anywhere. The identity primitive under every integration is live and provable right now; the integration guides themselves are proposed patterns for wiring that primitive into each part of the network.

On the roadmap

These feed 5G-security evidence into the tools a telecom SOC and an NF-vendor PSIRT already run. They are roadmap, not yet shipped, listed here so you can see where this goes:

• Microsoft Sentinel connector: shipped today, alongside the Splunk connector.
• OpenCTI threat-intelligence integration: shipped today.
• STIX 2.1 over TAXII export: roadmap. Maps identity and egress evidence onto standard TI transports for NIS2 and continuous-monitoring workflows.
• First-class typed --nf-instance-id argument: roadmap. Today the generic device_id already accepts an nfInstanceId, or any NFProfile identity.
• Independent witnessing of the transparency log: roadmap. Tamper-evident and Bitcoin-anchored today; external co-signing via C2SP tlog-witness is the next step.

Next

• NF identity: the shipped derivation these integrations all build on
• NF-impersonation cure: the primary wedge, verifiable identity at the SBI and the roaming border
• NESAS · NIS2 · 5G Toolbox: where the evidence lands, mapped honestly control by control