Summary

Telia’s new explanation makes the case clearer, not smaller.

According to NRK, Telia now says the exposure of location-related signaling data happened after a configuration change in a business-service platform in autumn 2023. The reported mistake was almost absurdly simple — a single header name was misspelled:

P-Access-Network-Info

became:

P-Access-Network-Id

That may explain the immediate mechanism. It does not explain the control failure. A robust telecom signaling boundary should not leak cell-level location context simply because a header name changes.

Telia found the typo

Telia has not given an interview to NRK about the case, but responded in writing. According to NRK’s reporting, the error happened during an update of a business-service platform in autumn 2023, while the platform was being adapted in connection with lawful-interception requirements. Telia also says it fulfilled those requirements both before and after the configuration change.

Lawful interception is supposed to be a controlled legal mechanism. It exists so that communications data can be disclosed under strict conditions, through defined channels, with legal thresholds and oversight. It is not supposed to create a side effect where location-related network context becomes visible through ordinary call signaling.

If Telia’s explanation is correct, the immediate failure was a configuration error. The deeper failure was architectural.

What the typo changed

The original issue involved SIP/IMS signaling in Telia Norway’s network. During normal call setup, signaling could expose access-network information about the recipient device. In the earlier write-up, I described the core issue like this:

No exploit. No intrusion. No bypass. Just standard protocol behavior returning more information than it should.

Original write-up: Telia: Location data leaked through telecom signaling.

The relevant field was:

P-Access-Network-Info: 3GPP-E-UTRAN-FDD;
  utran-cell-id-3gpp=242020af11e8b115

This is not an obscure field. P-Access-Network-Info is a SIP private header used in 3GPP environments. It can carry information about the access network used by the device, including radio access technology and cell identity. That is why it is useful — and why it is sensitive.

According to NRK’s new reporting, Telia’s configuration used or passed a misspelled variant:

P-Access-Network-Id

Telia’s systems appear to have been configured to strip the standardized P-Access-Network-Info header before signaling was forwarded beyond the intended domain. But when the same access-network context appeared under the non-standard name P-Access-Network-Id, the existing removal logic no longer recognized it. Based on the reported explanation, the boundary control appears to have depended on matching one exact header name, rather than on preventing sensitive cell-level network context from leaving the trusted signaling domain altogether.

That may explain the mechanism. It does not explain the failure.

This is where RFC 7315 matters

RFC 7315 describes private SIP P-headers used by 3GPP. It is not a Norwegian law, and not by itself a regulatory decision — but technically it is highly relevant. It describes the exact class of header involved here, the intended trust model around it, and the privacy risk created when access-network information leaves the environment where it belongs.

RFC 7315 says P-Access-Network-Info may carry access-network information such as radio access technology and radio cell identity, and that the information revealed in this header can be very sensitive. The security section is explicit about cell identity: 3GPP may use P-Access-Network-Info to carry sensitive information like cell ID, and that information must not be sent outside the 3GPP domain.

A proxy operating in a private trust domain where this header is supported is required to delete the header before forwarding messages outside that trusted domain. That is the trust-boundary principle. Internal network context can be useful inside the telecom domain. It should not leak beyond it.

A deny-list is not a boundary

Telia’s explanation points to a specific bug: the wrong header name. But that is exactly why the explanation is not enough. If the boundary control only removed one exact, known header, it was fragile by design.

For data this sensitive, the control question should never have been “is this header called P-Access-Network-Info?” It should have been “can this message contain cell-level access-network context when it leaves this domain?” Those are fundamentally different controls. The first is a narrow deny-list. The second is an actual boundary policy.

In this case, the misspelling appears to have bypassed the header-stripping logic because the system no longer recognized the field as the standardized one. Which raises the uncomfortable question: why was sensitive cell-level context allowed to leave at all, regardless of what the field was called?

Unknown P-headers should have been a warning sign

There is another uncomfortable detail. P-Access-Network-Info is a registered SIP header. The IANA SIP header registry lists it as such, and lists utran-cell-id-3gpp as one of its parameters. P-Access-Network-Id is not the same registered SIP header — I could not find P-Access-Network-Id in the IANA SIP header registry.

SIP header names are not just cosmetic labels — they are how systems classify, process, forward, strip and trust signaling information. If a non-standard P-* header carrying access-network context can travel through the system because it is not recognized, that is not reassuring. It is the opposite.

Unknown private signaling headers should be treated cautiously when messages cross trust boundaries, especially if they contain values that look like radio access information, cell identifiers or network-provided location context. A misspelled internal field should not become externally visible just because it is misspelled. That is exactly what boundary controls are supposed to prevent.

Telia points to configuration. Nkom points to responsibility.

There is also a governance issue here. Telia’s explanation places the error in a configuration change connected to a business-service platform and lawful-interception adaptation. That may be true. But Nkom’s position, as reported by NRK and stated in its own public notice, is the important one: providers are responsible for maintaining proper security in their own systems.

That is the correct line. The police may have lawful access requirements. The regulator may set obligations. But the operator owns the architecture, the configuration, the testing, the boundary enforcement and the production controls. A lawful-interception requirement does not explain why ordinary signaling exposed location-related context to callers — and it certainly does not explain why the condition reportedly lasted for around two and a half years.

The time factor changes the severity

A configuration mistake can happen. That is not the most troubling part. The troubling part is that this reportedly existed from autumn 2023 until it was discovered in March 2026 — around two and a half years.

In a telecom network, SIP signaling is not a rare path. Every call attempt, registration and session event creates signaling. If sensitive context is present in the wrong place, it is not a one-off failure. It is repeated behavior. From the outside, nothing necessarily looks broken: calls still connect, SIP messages are valid, the system behaves normally. There is no exploit signature, no intrusion, no bypass — just normal protocol behavior carrying more information than it should.

That makes this class of failure hard to detect if the operator is only monitoring availability, malformed traffic or attack patterns. Detection requires a different kind of visibility: knowing which internal context must never leave a given boundary.

The real root cause is not spelling

The typo may explain how the exposure happened. It does not explain why the exposure was possible. A misspelled header is only the visible defect — the deeper failure is that sensitive network context was able to cross a telecom trust boundary at all.

More precisely, cell-level access-network information appears to have been controlled through brittle header-name stripping, rather than through a stricter boundary policy that prevented this kind of context from leaving the trusted signaling domain in the first place.

If the public lesson becomes “someone misspelled a header,” the wrong problem gets fixed. The real lesson is sharper: sensitive telecom metadata must be constrained by architecture, classification and boundary enforcement — not by hoping every internal field is named exactly as expected.

Questions Telia still needs to answer

The new explanation raises more questions than it closes:

  • Why was cell-level access-network information present in a non-standard P-Access-Network-Id field?
  • Was this field generated by Telia’s own platform, a vendor system, an SBC, an IMS component or an integration layer?
  • Was the business-service platform treated as part of the trusted IMS domain?
  • Where exactly was the trust boundary supposed to be?
  • Was outbound signaling filtered using a deny-list of known sensitive headers rather than an allow-list of permitted external headers?
  • Were unknown P-* headers allowed to pass through signaling gateways?
  • Were there tests verifying that cell identifiers could not appear in signaling delivered outside the intended trust domain?
  • Did Telia inspect actual signaling responses after the 2023 configuration change?
  • Did any customer-facing, enterprise-facing or interconnect-facing SIP path receive this information?
  • How far did the exposed field propagate?
  • Why did Telia’s own monitoring not detect it for approximately two and a half years?

These are not rhetorical questions. They are the questions that separate a typo from a systemic control failure.

What this says about telecom trust

This case is uncomfortable because it is ordinary. It did not require malware, SS7 access, broken encryption or a compromised operator. It required normal telecom signaling to return more context than it should.

That is what makes telecom metadata so sensitive. It sits below the application layer and can describe where a device is, how it is connected and which infrastructure path a session takes. Users do not see it, and security teams can miss it if they are looking only for attacks rather than misplaced trust.

For the person being located, the technical distinction does not reduce the impact. If a cell identifier can be mapped to an approximate location, the privacy risk is real. NRK has already demonstrated that in practice.

Sources

Closing

Telia found the typo. That is not the same as explaining the failure. If one misspelled header was enough to make customers traceable over years, the real problem was never the spelling.

It was the boundary.

Tags Privacy Trust