DECT and DECT NR+ Explained: Cordless Radio, Security and 5G IoT

DECT (Digital Enhanced Cordless Telecommunications) is the ETSI radio standard behind most cordless desk phones, office headsets, enterprise handsets and many nurse call and alarm handsets. It runs in a band reserved for it, mainly 1 880 to 1 900 MHz in Europe, and splits that band into 10 carriers with 24 time slots each. DECT NR+ (ETSI DECT-2020 NR, the TS 103 636 series) is a new OFDM radio that shares the same band but adds mesh networking for industrial IoT, and the ITU recognises it as part of IMT-2020, the 5G family.

On security, the short answer is this. Classic DECT has authentication and encryption built into the standard, but the original algorithms were secret, short keyed and not always switched on by products. ETSI added AES based algorithms (DSAA2 and DSC2) to the standard in 2012 and the DECT Forum now runs a security certification. NR+ was designed with AES-128 ciphering and CMAC integrity at two layers from the start. What you should do is check that your handsets and base stations actually use encryption, keep IP DECT base station firmware current, close pairing windows, and treat NR+ gateways as network devices that need the same patching as any server.

Key takeaways

• DECT is defined in ETSI EN 300 175 parts 1 to 8. It uses FDMA and TDMA with time division duplex: 10 carriers, 10 ms frames, 24 slots (12 down, 12 up), up to 120 voice channels per base.
• ETSI lists 1 880 to 1 900 MHz as the most common allocation, with 1 900 to 1 920 MHz and 1 910 to 1 930 MHz in several countries outside Europe.
• The original DSAA and DSC algorithms are confidential, and DSC uses a 64 bit key. AES based DSAA2 and DSC2 arrived in EN 300 175-7 V2.4.1 (2012) and AES CCM in V2.5.1 (2013).
• Supported by the standard is not the same as used by your product. Check encryption per system, and ask for DSC2, early encryption and DECT Forum Security certification.
• DECT NR+ (DECT-2020 NR, TS 103 636) is a CP-OFDM radio with star and mesh topologies. ITU-R SG5 added "ETSI DECT 5G-SRIT" to M.2150 on 18 December 2021, published in February 2022.
• NR+ security has two layers, MAC per link and Convergence end to end, both with AES-128 ciphering and CMAC integrity, plus Secure Joining for provisioning.
• IP DECT bases, DECT servers and NR+ gateways run full software stacks that need a patch plan.

What is DECT and where is it used?

DECT is a radio access standard for short range wireless voice and data, developed by ETSI and maintained by its Technical Committee DECT. According to the DECT Forum, the first round of DECT standards was developed between 1988 and 1992, and the standard is defined in ETSI EN 300 175 parts 1 to 8, which ETSI keeps updating. The current versions of parts 1, 2 and 7 that we fetched for this post are V2.9.1, dated March 2022.

The DECT Forum, founded in 1997, is the industry association that promotes DECT alongside ETSI and runs certification programmes. It describes DECT as a family rather than one radio:

• Classic DECT: narrowband and wideband voice for residential cordless phones and enterprise systems (PBX handsets, headsets, intercom and conferencing systems), plus text messaging between handsets and applications.
• DECT ULE (Ultra Low Energy): a low power data profile for smart home sensors and actuators. The DECT Forum says ULE was announced in January 2011, that its physical layer is identical to DECT, and that its HAN-FUN application protocol (first released in November 2013) defines device profiles.
• DECT Evolution: changes to the DECT MAC, network layer and audio coding that add ultra reliable low latency communication (URLLC) and the LC3plus codec for professional microphones, intercoms, gaming headsets and controllers.
• DECT NR+ (DECT-2020 NR): a new OFDM radio for massive IoT and professional audio, covered in its own sections below.

Where you meet DECT in practice

In homes, DECT is the radio between a cordless handset and its base, which today is often built into a broadband router or home gateway. The DECT Forum's CAT-iq programme covers interoperability between handsets and these gateways.

In offices, hospitals, warehouses and retail, DECT shows up as multi-cell systems. The DECT Forum says enterprise systems from most vendors support more than 1 000 base stations and 10 000 handsets, with handover between bases as people walk. These systems connect to a PBX or, more often now, over IP to a unified communications platform using SIP. The Forum notes they often include messaging and personal security functions integrated with systems in hospitals, care homes, industry and retail.

Frequency bands: Europe, the US and elsewhere

ETSI EN 300 175-2, the physical layer part, defines the ten "classic" carriers in 1 880 to 1 900 MHz with this formula:

Fc = F0 - c × 1.728 MHz, where F0 is 1 897.344 MHz and c runs from 0 to 9.

Two worked examples make it concrete:

• Carrier 0: 1 897.344 MHz minus 0 gives a centre frequency of 1 897.344 MHz.
• Carrier 9: 9 × 1.728 MHz is 15.552 MHz, so 1 897.344 minus 15.552 gives 1 881.792 MHz.

Each RF channel spans from Fc minus 0.864 MHz to Fc plus 0.864 MHz, so ten channels at 1.728 MHz spacing fill 17.28 MHz of the 20 MHz band.

The same document says DECT carriers are specified for the whole range 1 880 to 1 980 MHz and 2 010 to 2 025 MHz, that 1 880 to 1 900 MHz is the most common allocation, and that outside Europe spectrum is also available in 1 900 to 1 920 MHz and in 1 910 to 1 930 MHz in several countries. Annex F adds carrier positions for the US ISM bands, 902 to 928 MHz and 2 400 to 2 483.5 MHz, noting that standard DECT could be used there since May 2002.

In the United States, cordless phones sold under the "DECT 6.0" label operate in a 1.9 GHz band set aside for this kind of equipment. The DECT Forum describes home DECT as running on "the dedicated 1.9 GHz radio band". The exact US channel plan is set by the US regulator rather than ETSI, so check your equipment's regulatory label if you need the precise frequencies.

Dedicated spectrum keeps DECT out of the crowded 2.4 GHz band. It still shares its band with other DECT systems.

How does DECT work?

Frames, slots and duplex

DECT combines frequency division multiple access (ten carriers) with time division multiple access (slots on each carrier). Per the DECT Forum's technical summary, each carrier carries 10 ms frames divided into 24 time slots. The first 12 slots carry downlink traffic from the base to handsets and the last 12 carry uplink traffic from handsets to the base. That pairing of one downlink and one uplink slot in the same frame is time division duplex (TDD), so a single carrier serves both directions.

Multiply it out and a base station can, in principle, run 10 carriers × 12 duplex slot pairs = 120 simultaneous voice channels.

DECT devices pick channels themselves; EN 300 175-2 calls the procedure instant Dynamic Channel Selection (iDCS). It is the reason many DECT systems can sit close together without manual frequency planning. The DECT Forum quotes typical ranges of about 50 metres indoors and up to 300 metres outdoors.

Fixed parts, portable parts and identities

The standard calls the base side the Fixed Part (FP) and a handset the Portable Part (PP). A PP has to be registered to an FP before it can make calls. In the language of EN 300 175-7, that registration is "subscription registration": the infrequent process where a subscriber obtains access rights, and during which "all the secret parameters required for the security services are made known" to the handset and the system operator.

In practice this is the pairing you do when you put a base into registration mode and enter a PIN on the handset. The standard's term for such a code is the Authentication Code (AC). During registration the two sides derive a 128 bit User Authentication Key (UAK) that is stored in both and used for every later authentication. That makes the registration window the most sensitive moment in the life of a DECT system, which we come back to in the step by step section.

Authentication and ciphering, the original algorithms

EN 300 175-7 defines the DECT security services: authentication of the handset (PT), authentication of the base (FT) and mutual authentication, data confidentiality (encryption of the air interface) and key management. Two algorithms were defined at the start:

• DSAA, the DECT Standard Authentication Algorithm.
• DSC, the DECT Standard Cipher, a stream cipher producing the key stream that encrypts slots on the air.

The standard is direct about their status: "The DECT Standard Authentication Algorithm (DSAA) and the DECT Standard Cipher (DSC) are confidential." They are not printed in the standard and are "made available to DECT equipment manufacturers". The key diagrams in the same document show a derived cipher key (DCK) of 64 bits when DSC is used.

Authentication is a challenge and response. The base sends a random value; the handset computes a response from the random value and the UAK; the base compares it with its own calculation. A side output of that calculation is the cipher key for the call. Encryption then runs at the MAC layer, slot by slot, using the key stream from the cipher.

The AES based algorithms: DSAA2, DSC2 and CCM

EN 300 175-7 records two later changes:

• "The DECT Standard Authentication Algorithm #2 (DSAA2...) and the DECT Standard Cipher #2 (DSC2...) are based on AES and were introduced with the revision V2.4.1 of the present document." ETSI's own publication directory shows V2.4.1 published in April 2012.
• "The CCM Authenticated Encryption Algorithm (CCM...) is also based on AES and was introduced with the revision V2.5.1." The directory shows V2.5.1 published in August 2013.

Unlike DSAA and DSC, the standard says DSAA2, DSC2 and CCM "are publicly available" and specifies them in its annexes, with test vectors. Keys in the DSAA2 family are 128 bits, and the cipher key can be 64 or 128 bits depending on which cipher is negotiated. Separately, the DECT Forum describes ULE as using "strong 128 bit AES encryption" compared with the 64 bit encryption of classic DECT.

Two other features in the same part matter for real deployments:

• Early encryption. The standard describes early encryption as a mechanism "to ensure the fast activation of encryption at the beginning of any call", using pre-computed Default Cipher Keys so that even call setup messages are encrypted. The text notes that those setup messages "may contain the called party number", which is exactly the metadata you would not want in the clear.
• Re-keying. The standard defines procedures for changing the cipher key during a long call, including on systems with wireless relay stations.

What changed for buyers

These additions do nothing for equipment that does not implement them. Handsets that only speak DSAA and DSC keep using them, and a base with encryption switched off does not encrypt, so the real questions are about products and configuration.

What did the 2008 to 2010 DECT security research show?

From late 2008, independent academic researchers published analyses of DECT as it was then deployed. The broad findings reported at the time, described here at the concept level only, were:

1. Some cordless products of that era did not switch encryption on for calls at all, even though the standard supported it.
2. Later work analysed the confidential DSAA and DSC algorithms and reported weaknesses, which made a 64 bit key from a secret algorithm a poor long term foundation.

We have not linked those papers here. This explainer limits itself to sources from ETSI, the DECT Forum and the ITU, and the dates and details of the academic work should be read from the papers themselves. What the standards record does show is the response.

How the DECT Forum responded with certification

The DECT Forum runs three certification streams today. Its certification page says the DECT Security certification "ensures that cordless devices comply with the latest ETSI security standards" and calls it especially crucial in sectors such as healthcare, banking and government, where the enterprise market demands high security standards. CAT-iq certification covers interoperability between residential handsets and home gateways. An NR+ certification programme is planned for late 2026, starting with building automation.

The process, as the Forum describes it, is that members have products tested by established test houses, the test house informs the Forum, members apply and pay a fee, and certified products are listed on the Forum website. That listing is the practical thing for a buyer: if a product claims the security certification, you can look for it on the Forum's certified products list.

The page does not publish detailed test requirements, and a certified handset paired to a base with encryption disabled is still unencrypted.

What is DECT NR+?

DECT NR+ is the DECT Forum's marketing name for ETSI DECT-2020 New Radio, specified in the ETSI TS 103 636 series. It is a different radio from classic DECT: OFDM based, built for data first, and able to form self-organising mesh networks. It is designed to coexist with classic DECT and DECT Evolution in the existing DECT bands.

The specification set

ETSI TS 103 636-1 lists five parts in Release 2: Part 1 Overview; Part 2 Radio reception and transmission requirements, including the list of supported frequency bands; Part 3 Physical layer; Part 4 MAC layer, including MAC security; and Part 5 DLC and Convergence layers, including routing and end to end security. ETSI's directory shows TS 103 636-1 V1.1.1 published in July 2020 and the current V2.2.1 (Release 2) in May 2026. Part 4 is at V2.2.1 too.

ITU recognition as part of IMT-2020

The ITU-R Working Party 5D IMT-2020 page tells the story in its own words. Recommendation ITU-R M.2150, "Detailed specifications of the terrestrial radio interfaces of IMT-2020", was first published in February 2021. During 2021 further candidates were evaluated, and "a new RIT has been included in the draft revision: 'ETSI DECT 5G-SRIT'". ITU-R says it "has fulfilled all the minimum requirements (technical performance, services and spectrum)" as assessed by Working Party 5D with Independent Evaluation Groups. Study Group 5 adopted that first revision "at its last meeting on 18 December 2021", and the ITU recommendation page lists M.2150-1 dated February 2022.

TS 103 636-1 explains what the SRIT is: DECT-2020 NR is recognised "as a component RIT fulfilling the IMT-2020 requirements" for the URLLC and mMTC use scenarios, and the set of radio interface technologies called "DECT 5G SRIT" involves 3GPP NR and DECT-2020 NR. Revisions 2 (December 2023) and 3 (February 2026) added enhanced capabilities for it, and work on revision 4 has started. The DECT Forum's own announcement, dated 24 February 2022, calls it "the first global non-cellular 5G technology" and says the Forum would promote it under the name NR+.

How the NR+ radio works

TS 103 636-1 summarises the physical layer this way: it "employs Cyclic Prefix Orthogonal Frequency Division Multiplexing (CP-OFDM) combined with Time Division Multiple Access (TDMA) and Frequency Division Multiple Access (FDMA) in a Time Division Duplex (TDD) communication manner." Further points from the same overview and the DECT Forum's NR+ page:

• It is "in principle suited for addressing frequency bands below 6 GHz", with multiple numerologies (subcarrier spacings and matching cyclic prefix lengths and FFT sizes) to fit different channel bandwidths.
• Turbo coding and Hybrid ARQ with incremental redundancy give fast retransmission and high reliability. Release 2 supports link adaptation, transmit and receive diversity and MIMO up to 8 streams.
• The DECT Forum says there are 24 time divided slots per radio frame, that beacon periods range from 10 ms to 32 seconds, and that latency can go down to 1 ms between devices.
• Transmit power is dynamically controlled. A DECT Forum webinar Q&A gave the range as minus 40 to plus 23 dBm.
• It supports IPv6, which the DECT Forum says lets IP layer security, including public key cryptography, protect device management and firmware updates.

Topologies and roles

TS 103 636-1 describes three ways to build a network:

1. Point to point and point to multipoint links, for cable replacement. One radio device (RD) runs in Fixed Termination (FT) mode and sends beacons; others associate in Portable Termination (PT) mode.
2. Star, or cellular, networks, where RDs in FT mode act as base stations and RDs in PT mode associate with them, much like classic DECT.
3. Mesh networks, which are "based on a clustered tree topology where each RD decides the next hop individually". An RD in a mesh can run FT and PT modes at once, so it is both a leaf of its parent and a parent to its own cluster. The DECT Forum notes that a mesh has no network wide synchronisation; each node synchronises to its parent's beacon.

Mesh routing climbs the tree towards a sink, an RD with a connection to back end systems, and the overview says a network can have several back ends sharing the same mesh.

How a mesh IoT radio differs from cordless voice DECT

The practical difference for security teams is scale. A cordless voice system has dozens or hundreds of handsets that a person paired by hand. A metering or building mesh may have thousands of nodes joined with "zero-touch automatic network joining", in the DECT Forum's words. Every security property then depends on how keys get onto devices, how the network decides who can join, and whether firmware can be updated safely in the field.

How is DECT NR+ secured?

Two layers: MAC and Convergence

TS 103 636-1 section 7 states that the "security architecture relies on two independent security layers operating at MAC and CVG protocol layers." The MAC layer security protects each radio link between two RDs. The Convergence (CVG) layer security is end to end, between the source's CVG endpoint and the target's, for example between a sensor and its back end application.

The overview is precise about the algorithms: "Both security layers provide ciphering and integrity protection with AES-128 and CMAC respectively with separate ciphering and integrity keys." When MAC security is active it covers all data transmissions "including also network beacon and cluster beacon messages."

MAC security Mode 1, in detail

TS 103 636-4 (MAC layer), clause 5.9, defines Mode 1:

• Two keys per RD, one for integrity and one for encryption. The method is "transparent for the method used for RD authentication and key distribution", which means the MAC spec does not fix how keys arrive; that is the job of provisioning.
• Integrity: a Message Integrity Code (MIC) computed with CMAC (OMAC-1) over the complete MAC PDU, using AES-128 per NIST SP 800-38B, then truncated to 5 octets and appended.
• Ciphering: AES-128 in counter (CTR) mode. The PDU is ciphered from the MAC security information element onwards, including the MIC.
• Counters and nonces: a Hyper Packet Counter feeds the initialisation vector, and three nonces (Beacon Nonce, Association Nonce, Data Nonce) are used "to prohibit potential replay attacks" in association requests, beacons and random access transmissions.
• Counter discipline: initial values "shall be a true random value", counters increase monotonically so the same value is not reused with the same keys, and "the uniqueness of these values shall be maintained over the device boot or reboots."

That last requirement is a firmware engineering requirement as much as a radio one. A device that resets its counters on reboot and reuses a CTR mode counter with the same key breaks the confidentiality the cipher is supposed to give. It is a good question to put to any NR+ module or gateway supplier: how are counters persisted across reboots and power loss?

Plain text versus ciphered beacons

TS 103 636-4 also explains a trade-off that every NR+ network owner makes. The beacon "can be transmitted as plain text without MIC or ciphered". If it is plain text, the FT "provides association for any other RDs that may or may not have the MAC security key(s)". If it is ciphered, "association is only possible for RDs that already have MAC security keys available."

An open beacon suits commissioning; a ciphered beacon keeps unknown devices out but needs keys provisioned in advance.

Secure Joining and provisioning

TS 103 636-1 section 7.2 describes Secure Joining, which "enables communication for authentication and provisioning process including security key distribution between RD and the Provisioning Server for an RD that does not have valid MAC and/or CVG security credentials." Three roles take part:

• the Provisioning Client on the new device,
• a Provisioning Proxy on an RD that relays for it (in a mesh, a nearby router node),
• the Provisioning Server in the back end.

Secure Joining "is enabled when needed by the network owner. It can be enabled system-wide or only at a certain location of the network," and it "is agnostic on the actual authentication and provisioning protocols." The overview also describes the alternative: devices loaded with the "necessary MAC and CVG end-to-end security keys, and other system configuration parameters in advance."

So the standard supplies good cryptographic building blocks, while the provisioning protocol, key sources, Secure Joining scope and CVG settings are left to each deployment.

Where is NR+ being deployed?

The DECT Forum says initial implementations focus on "smart metering, building automation, professional audio and industrial applications". Its IoT page describes smart grid and smart metering, smart buildings (access control, emergency systems and alarms), smart cities (for example streetlights acting as mesh backbones that also serve parking and waste sensors) and Industry 4.0 shop floors.

Some dated markers from Forum pages:

• A DECT Forum webinar summary said NR+ chipsets were in production from December 2023, with a commercial mesh stack for mains powered devices such as smart meters and street lighting due in early 2024 in the 1 880 to 1 900 MHz band.
• The DECT Forum announced a first NR+ interoperability demonstration between two building automation manufacturers for smart buildings.
• On 18 December 2025, the Forum welcomed European Commission Implementing Decision 2025/2425 on the 3.8 to 4.2 GHz band, saying it strengthens the regulatory framework for DECT-2020 NR and noting NR+ can operate in both licensed and licence exempt spectrum below 6 GHz.
• The Forum's NR+ certification programme is planned for late 2026.

Comparison: DECT, NR+, Wi-Fi, LoRaWAN and cellular IoT

The DECT columns below come from the ETSI and DECT Forum sources in this post. The other columns are kept general and describe categories rather than exact figures, because spectrum rules and ranges vary by country, product and configuration.

Dedicated spectrum helps reliability but does nothing for confidentiality, which still depends on encryption being on. NR+ is the only entry that is both licence exempt and part of IMT-2020, which is why the DECT Forum pitches it for subscription free private 5G networks. For deeper looks at neighbouring radios, see our posts on LoRaWAN architecture and keys and Zigbee, Thread and Matter.

Decision table: what to ask before buying DECT or NR+

Step by step: check encryption, update firmware and tighten pairing

The steps below are defensive checks on equipment you own or manage. Screens and command names differ by manufacturer, so treat the commands as patterns and use your product's documentation for exact menus. Nothing here involves capturing or decoding radio traffic.

Step 1: Build an inventory

List every DECT and NR+ component: home gateways with DECT, single cell bases, IP DECT base stations (multi-cell), DECT servers or controllers, repeaters, handsets, headsets, alarm and nurse call handsets, ULE sensors, NR+ gateways and NR+ modules in meters or controllers. For each, record model, hardware revision, firmware version, management IP, support end date and owner.

For IP connected devices, pull the system description over SNMPv3 where the device supports it. The example uses placeholder credentials and a documentation range address:

# Read sysDescr (often includes model and firmware) from an IP DECT base station.
# Replace user, passphrases and address with your own; never use SNMPv1/v2c communities on a shared network.
snmpget -v3 -l authPriv \
  -u dect-monitor -a SHA -A 'auth-passphrase' \
  -x AES -X 'priv-passphrase' \
  192.0.2.21 1.3.6.1.2.1.1.1.0

Step 2: Check the management plane

IP DECT bases and DECT servers have web or API management interfaces. Check they use TLS with a valid certificate and that you know which version of the interface you are talking to:

# Show the certificate subject, issuer and expiry of a base station's management UI.
openssl s_client -connect 192.0.2.21:443 -servername dect-base-01.example.internal </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -enddate

If the device only offers plain HTTP or Telnet for management, put it behind a management network that only administrators can reach and raise it with the vendor.

Step 3: Confirm that calls are encrypted

1. In the DECT server or base station admin interface, find the security or air interface settings. Look for options such as "encryption", "require encryption", "early encryption" or the cipher in use (DSC or DSC2).
2. Check whether the system can show per handset or per call encryption status. Many enterprise systems show it in a handset list or call log.
3. On handsets, look for an encryption indicator or a status screen. Some handsets show a symbol or a warning when a call is not encrypted.
4. Where the system supports it, set it to refuse calls from handsets that cannot encrypt, after you have checked no critical handsets would be cut off.
5. For home use, check the gateway's DECT or telephony settings for an encryption or "DECT security" option and make sure it is on.

Write down what you found per site. "We assume it is encrypted" is the finding you want to replace.

Step 4: Update base station and server firmware safely

Firmware updates do not erase handsets, but a failed update can leave a base unusable and a wrong configuration restore can deregister handsets. Before each update:

1. Export and store the current configuration and the list of registered handsets.
2. Confirm the device model and hardware revision match the firmware you downloaded.
3. Verify the firmware file against the hash the vendor publishes:

# Compare the downloaded image's SHA-256 with the value on the vendor's release page.
shasum -a 256 dect-base-firmware-x.y.z.bin

4. Update one base or one site first, check calls, handover and alarms, then roll out in stages.
5. After the update, re-check the security settings from Step 3, since some updates reset defaults.

Step 5: Tighten registration (pairing)

1. Keep the base or DECT server out of registration mode except while you are registering a handset. Many systems allow a time limited registration window; use the shortest practical.
2. Change the registration PIN (the Authentication Code) from its default, and do not reuse one PIN across every site.
3. Register handsets in a controlled place, by an administrator, not by end users walking up to a base.
4. Review the list of registered handsets monthly. Remove handsets that are lost, replaced or no longer in use, so their keys stop working.
5. Log registration and deregistration events to your central logging system, and alert on registrations outside change windows.

A pattern for searching forwarded syslog from DECT servers, assuming your system logs registration events with a recognisable keyword:

# Find handset registration events in the last day of forwarded DECT server logs.
grep -iE 'registr|subscri' /var/log/remote/dect-*.log | tail -n 50

Step 6: Segment the network

IP DECT bases need to reach the DECT server, the SIP platform, time and logging services, and administrators. They do not need the internet or the user network. Put them on a voice or management VLAN and allow only those flows at the router or firewall.

For SIP and media protection between the DECT server and the call platform, see our SIP and RTP explainer.

Step 7: Supervise alarm and safety links

If DECT carries alarms (nurse call, lone worker buttons, fire or intrusion notifications), confirm the system supervises the link: handsets and alarm devices should check in periodically, and a missed check in should raise an alarm of its own. Test it by switching a test handset off and confirming the alert arrives where expected.

Step 8: For NR+, check the security configuration at commissioning

1. Confirm MAC security is enabled and beacons are ciphered once commissioning ends.
2. Confirm Secure Joining is enabled only in commissioning zones or windows, and record which provisioning protocol it uses.
3. Turn on CVG end to end security for sensitive applications such as access control and metering data.
4. Ask the supplier how security counters are kept unique across reboots (TS 103 636-4 requires it).
5. Patch NR+ gateways like any other network appliance, with a supported OS and an update channel.

Step 9: Ask for an SBOM and check the components

Ask your vendor for a software bill of materials for base station firmware, DECT server software and NR+ gateways. If they provide one in CycloneDX or SPDX format, you can scan it for known vulnerable components:

# Scan a vendor-supplied SBOM for components with known vulnerabilities; results are written as JSON under ./output
safeguard scan --sbom dect-server-firmware-sbom.cdx.json

This checks the listed components against vulnerability databases; it does not test the radio or the firmware image.

Common mistakes

Assuming every cordless call is encrypted. The standard has supported encryption since the start, but products decide whether to use it, and older handsets may only speak the confidential 64 bit DSC. Check per system, as in Step 3, rather than assuming.

Never updating IP DECT base stations. Multi-cell bases sit on the network for years. They run full software stacks and receive security fixes like any other appliance. Put them in your patch process and your asset inventory, with a support end date.

Leaving registration open. A base left in registration mode, or a DECT server with a default PIN, lets any compatible handset in range register and receive the long term keys. Close the window and change the PIN.

Running DECT alarm links without supervision. A personal safety button that is out of range or has a flat battery fails silently unless the system checks in periodically and raises an alert when it does not.

Keeping legacy handsets that force old algorithms. One old handset can hold an entire system on DSC. Plan replacements so you can switch the system to refuse legacy encryption.

Treating NR+ beacons as harmless. Plain text beacons allow open association. That is useful during commissioning and a weakness afterwards.

Leaving Secure Joining enabled network wide. The standard lets owners enable it in one location or system wide. Limit it to where and when devices are commissioned.

FAQ

Is DECT encrypted?

The DECT standard supports encryption of the air interface, and modern systems can use AES based DSC2. Whether your calls are encrypted depends on the product and its configuration. Check the system's security settings and handset indicators.

What frequency does DECT use?

The most common allocation is 1 880 to 1 900 MHz, used across Europe and many other countries, with ten carriers 1.728 MHz apart. ETSI lists 1 900 to 1 920 MHz and 1 910 to 1 930 MHz in several countries outside Europe. US "DECT 6.0" phones use a 1.9 GHz band set aside for them.

What is the difference between DECT and DECT 6.0?

DECT 6.0 is a North American product label for DECT phones that operate in the US 1.9 GHz band. The underlying technology is the same ETSI standard; the "6.0" is not a version number of the standard.

What are DSAA2 and DSC2?

They are the AES based DECT Standard Authentication Algorithm #2 and DECT Standard Cipher #2, added to ETSI EN 300 175-7 in version 2.4.1, published in 2012. Unlike the original DSAA and DSC, they are publicly specified in the standard.

What is DECT NR+?

DECT NR+ is the DECT Forum's name for ETSI DECT-2020 New Radio (TS 103 636 series), an OFDM radio with mesh networking for IoT and professional audio. It shares DECT spectrum with classic DECT and is part of the ITU's IMT-2020 family.

Is DECT NR+ really 5G?

ITU-R included "ETSI DECT 5G-SRIT", which involves DECT-2020 NR, in revision 1 of Recommendation ITU-R M.2150, adopted by Study Group 5 on 18 December 2021 and published in February 2022. That places it in IMT-2020, the ITU definition of 5G, for the URLLC and mMTC use scenarios. It is not a cellular network and needs no operator subscription.

How is DECT NR+ secured?

At two layers. MAC security protects each radio link, including beacons, with AES-128 counter mode ciphering and a CMAC integrity code using separate keys. Optional Convergence layer security adds end to end protection between a device and its back end. Secure Joining provides a path for provisioning keys to new devices.

Can DECT phones be intercepted?

A DECT call that is not encrypted can be recorded by suitable radio equipment within range, which is why checking encryption matters. An encrypted call using DSC2 is protected by AES. Old systems using only the original DSC rely on a 64 bit key from a confidential algorithm, which is a weaker basis than AES.

Where Safeguard fits

Safeguard's fit here is indirect. It does not test DECT or NR+ radios, inspect air interface encryption, scan firmware images or manage devices. It helps with the software around them: if your team builds an NR+ back end, a provisioning server, gateway software or a DECT to SIP integration, Safeguard can scan those repositories, container images and SBOMs, show which projects contain a given component and version, and gate builds on policy. If you buy the equipment, a vendor SBOM gives you something concrete to check.

DECT and NR+ security lives mostly in radio settings and vendor firmware, which no dependency update can fix for you. The software you build around them, such as NR+ back ends, provisioning servers, gateway applications and SIP integrations, still pulls open source packages and container images on every rebuild, and that is where these options apply.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The demos below show the software side only. None of them touches a DECT or NR+ radio.

This first demo is a real CLI session: install, open the interactive terminal, ask it to fix a vulnerable lodash version in a repository, and watch it read the finding and advisory, edit the manifest, and run the install and tests. The CLI asks before any command that changes something and pushes nothing. The same flow applies to the repository for an NR+ back end, a provisioning server or a DECT to SIP integration service.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code, and then scans from the terminal. For a team that builds gateway software or receives vendor SBOMs for base station firmware, that is how you would scan them on a build host inside your own network.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It is a quick way to ask which of your projects ship a given library version, for example the TLS library inside a gateway image, without leaving a chat.

Click through it at your own pace, or open it full screen.

Try it on your own build: download Safeguard and read the CLI docs.

Quick check

Sources

• ETSI EN 300 175-7 V2.9.1 (2022-03), DECT Common Interface Part 7: Security features (PDF)
• ETSI EN 300 175-7 publication directory (version history)
• ETSI EN 300 175-2 V2.9.1 (2022-03), DECT Common Interface Part 2: Physical layer (PDF)
• ETSI EN 300 175-1 V2.9.1 (2022-03), DECT Common Interface Part 1: Overview (PDF)
• ETSI TS 103 636-1 V2.2.1 (2026-05), DECT-2020 NR Part 1: Overview, Release 2 (PDF)
• ETSI TS 103 636-1 V1.1.1 (2020-07), DECT-2020 NR Part 1: Overview (PDF)
• ETSI TS 103 636-1 publication directory
• ETSI TS 103 636-4 V2.2.1 (2026-05), DECT-2020 NR Part 4: MAC layer, Release 2 (PDF)
• ETSI, Wireless and mobile technologies (TC DECT overview)
• ITU-R Working Party 5D, IMT-2020
• ITU-R Recommendation M.2150, versions and dates
• DECT Forum, home page
• DECT Forum, Classic DECT
• DECT Forum, Cordless telephony
• DECT Forum, Certification
• DECT Forum, DECT ULE
• DECT Forum, DECT Evolution
• DECT Forum, NR+
• DECT Forum, Internet of Things
• DECT Forum, ITU-R Approves DECT-2020 as New 5G Technology Standard (24 February 2022)
• DECT Forum, EC Decision 2025/2425 and DECT NR+ in 3.8 to 4.2 GHz (18 December 2025)
• DECT Forum, DECT NR+ on General Availability
• DECT Forum, DECT NR+ Standard Upper Layers Technology

Last reviewed: 25 October 2026.