Is PSTN secure, and can PSTN calls be encrypted?

The PSTN was built to deliver calls reliably. ITU-T G.711, the network's basic voice coding standard, sets a sampling rate of 8,000 samples per second and two encoding laws. It is a codec: it describes how speech becomes numbers, and any encryption has to come from the link that carries those numbers or from the devices at each end. The safeguards that ITU-T Q.700 lists for SS7, the signaling system switches use to set up calls, are aimed at transmission faults and link failures.

Keeping a call confidential is left to how each carrier protects its lines, switches and signaling links, and those protections have been tested. In a 2024 public notice, the FCC's public safety bureau said SS7 and its successor protocol, Diameter, are used to process and route calls and text messages between networks, and that "numerous reports have called attention to security vulnerabilities present within SS7 networks." The reports it cites are about tracking a subscriber's location, which is a different thing from listening to a call. An FCC advisory council had earlier recommended firewalls, monitoring and filtering on signaling traffic, and it advised the industry to encourage subscribers to use the encryption available to them.

Carrier networks themselves have also been breached. In December 2024, CISA reported that actors affiliated with the Chinese government had targeted commercial telecommunications infrastructure. The agency's guidance says the activity led to the theft of customer call records and to the compromise of private communications for a small number of highly targeted people.

Whether that makes the PSTN secure enough depends on what a call needs protection from. The telephone network gives a caller no way to confirm how the whole path is protected. A conversation that has to stay private from everyone between the two parties needs encryption the callers can account for.

A modern call usually crosses several networks, and each leg can have different protection, depending on how it is configured. Signaling and audio also use different protocols.

For signaling, the SIP standard is plain about the limit. RFC 3261 says "TLS offers strictly hop-by-hop security," and that a device sending a request over TLS to its proxy "has no assurance that TLS will be used end-to-end." For audio, SRTP "can provide confidentiality, message authentication, and replay protection" to the voice packets. It protects them between the two devices that share its keys, and those two devices are often your phone and your provider's equipment, with the other person's phone outside the session.

The legs nearest you are the ones with published documentation, and Microsoft's Direct Routing is a clear case. It connects Teams to a telephone carrier through a session border controller, or SBC, that the customer supplies. Microsoft's planning guide requires SIP over TLS for signaling and SRTP for audio between that SBC and Teams, along with a trusted certificate on the SBC. The same guide lists "one or more PSTN trunks connected to the SBC" as a separate requirement. Microsoft's encryption rules cover the Teams side of the SBC. The trunk on the other side is arranged between you and your carrier.

Atlantech Online, a carrier that sells Teams calling, states the boundary on its own network. Its Operator Connect page says the company encrypts calls inside its network and that "voice signaling and media remain encrypted until the call exits to the PSTN." For its government cloud service, Atlantech's FAQ on end-to-end encryption is more specific. Calls to outside numbers are protected by TLS on the signaling path and SRTP on the media path between the Teams client and the SBC. Past that point, the FAQ says, the encryption chain "breaks at the SBC gateway" as the call moves to the traditional telephone network.

On this route, the reason is the SBC's role. It is one end of the encrypted Teams session, so it holds the keys and decrypts the call in order to pass it on. What happens after the SBC depends on the next link. It may be another IP connection, encrypted or not, or it may be a circuit. Knowing how your own leg is protected doesn't tell you how the rest of the path is.

Suppose a manager on Teams calls a client's mobile number. Microsoft says network communications in Teams are encrypted by default with TLS and SRTP, so the leg from the laptop to Microsoft is covered. If Atlantech is the company's Operator Connect carrier, Atlantech says the call stays encrypted inside its network until the PSTN handoff. From there it passes to the client's mobile provider, directly or through other carriers. Each of those hops has its own arrangement, and the manager has no view of any of them.

We trace the same path, with its signaling, in how the PSTN works. The choice between a customer-run SBC and a carrier-run one is covered in Direct Routing versus Operator Connect.

A call is encrypted end to end when the two endpoints hold the keys and nothing between them does. That takes compatible equipment or software on both sides.

It has been done over ordinary phone lines before. The STU-III secure telephone was developed by the US National Security Agency in 1987 "for secure voice communication over non-secure analogue PSTN telephone networks," according to the Crypto Museum. The phone digitized speech with a vocoder and encrypted it before it reached the line, and the network carried the result like any other call. Both parties needed a compatible unit.

Today the common route is an encrypted call between two users of a service that supports it, and that call never touches the PSTN. Teams is one example. Microsoft's end-to-end encryption documentation says that with the feature on, "the service can't decrypt media," which is why some features that depend on the service stop working. For one-to-one calls it "is disabled by default" in the organization-wide policy, so an administrator has to allow it, and users then turn it on in their own Teams settings. The same page lists "People dialing by phone (PSTN)" among the things unavailable in an end-to-end encrypted meeting.

That last item says something narrow. Teams doesn't extend its end-to-end guarantee to a participant who dials in by phone. It says nothing about how the carrier hops on that participant's call are protected. Atlantech draws the same line for its government cloud customers. Its FAQ says end-to-end encryption is available for Teams-to-Teams calls inside the tenant and recommends those calls, in place of calls to outside phone numbers, for sensitive discussions.

CISA's 2024 guidance gives the same advice to the senior officials it was written for: "Use only end-to-end encrypted communications." For most businesses, the practical version is to sort calls by what they need. An ordinary call to a phone number can be protected on your own leg, where your service is configured for it, and that is the part you can confirm with your provider. A conversation that has to be private from everyone in between belongs on a service where both endpoints support end-to-end encryption.