5G RedCap Isn’t an IoT Breakthrough. It’s a Cost Correction.

Every connectivity vendor with a blog has published the same RedCap post. You know the one: “Goldilocks tier,” a chart comparing megabits per second, a market-size stat pulled from an analyst report, and a promise to “future-proof” your deployment. But there’s a more useful way to look at RedCap.

We’re going to say the part they leave out. RedCap is not an IoT breakthrough. It is a cost correction.

5G New Radio was built for applications that need serious bandwidth or extremely low latency. Most connected devices don’t need either. They need enough bandwidth, a reasonable bill of materials, and connectivity that works wherever the device ends up.

RedCap makes 5G more practical for that middle ground. But the radio is only half the decision. Because when you choose RedCap, you’re also choosing where that RedCap device can actually connect, and that can quietly turn into a carrier decision.

And that’s where the conversation gets interesting.

What is 5G RedCap?

RedCap, Reduced Capability, originally called NR-Light, is a 3GPP Release 17 specification designed to simplify 5G New Radio for devices that don’t need the capabilities of a smartphone or a full 5G modem.

It reduces the complexity of the radio by cutting capabilities that many non-phone devices do not need:

• Maximum bandwidth drops from 100 MHz to 20 MHz.
• Receive branches drop from four to one or two.
• Half-duplex FDD becomes an option instead of full-duplex.

The result is a simpler, less expensive 5G modem that can still connect to a 5G core.

The honest comparison is to LTE. Ericsson maps RedCap’s capabilities onto 4G device categories 2, 3, and 4. Peak rates land around 85–225 Mbps down and 90–120 Mbps up on FDD, with lower rates on TDD. So if you are shipping a device on Cat 4 today, RedCap is its 5G-era equivalent. That’s the whole story, and it is a good story. It just isn’t quite as revolutionary as the marketing around it suggests.

Why RedCap Exists: The part module vendors skip

5G NR was engineered for two different extremes: high-bandwidth mobile broadband, and ultra-reliable low-latency communications. That makes sense for smartphones, industrial control systems, and other demanding applications. But it also made 5G unnecessarily expensive for a large middle tier of devices:

• Industrial gateways
• Routers
• Cameras
• Point-of-sale terminals
• Telematics units
• Mid-tier trackers
• Connected monitoring equipment

These devices don't need gigabit speeds. They need the right amount of connectivity at the right cost. RedCap addresses that gap. It fixes the price, not the physics. It exists because 5G modems cost too much for devices that were never going to use gigabit throughput. Calling that an IoT breakthrough oversells it. Calling it what it is, a cost correction that finally makes 5G viable for mid-tier hardware, is both more accurate and more useful to anyone actually making a procurement decision.

RedCap is not an LPWA technology

This is one of the easiest places to get the RedCap story wrong.

RedCap does not replace NB-IoT or LTE-M. 3GPP did not define RedCap as an LPWA technology. It does introduce efficiency improvements compared with a full 5G NR modem: fewer receive branches, narrower bandwidth, optional half-duplex FDD, extended DRX, and other optimizations.

But those improvements shouldn’t be confused with multi-year LPWA battery life.

If your device sends a few hundred bytes a day and needs to run for years without intervention, NB-IoT or LTE-M is still the better fit. RedCap is solving a different problem. Think of the tiers this way:

LPWA is about doing less with less power. RedCap is about bringing the cost and complexity of 5G down to a more practical level. Those aren't the same thing.

eRedCap is where the story gets interesting

If RedCap addresses the Cat-4 tier, its evolution (enhanced RedCap, or eRedCap) moves the conversation further down the cellular IoT stack. Release 18 adds eRedCap with peak throughput around 10 Mbps in both directions, a narrower data channel, and extended eDRX capabilities.

Its target is another huge segment of cellular IoT: LTE Cat-1 and Cat-1bis. That includes devices like:

• Asset trackers
• Telematics units
• Payment terminals
• Metering gateways
• Connected appliances
• Low-throughput industrial devices

This distinction is important.

eRedCap is not the new LTE-M. It’s closer to the 5G successor for Cat-1/Cat-1bis devices. The specification is complete. What’s still developing is the ecosystem around it: silicon, modules, certifications, and network support.

So eRedCap is something to design toward, not necessarily something every device team should build its immediate roadmap around. And that brings us to the technology that makes the eRedCap story particularly interesting.

Don’t overlook Cat-1bis, the quiet hero of cellular IoT

Before eRedCap can matter, it's worth understanding why Cat-1bis has become such an important part of cellular IoT.

LTE Cat-1bis is essentially Cat-1 simplified to use a single receive antenna instead of two. The result is a simpler antenna design, smaller footprint, and lower bill of materials, while maintaining around 10 Mbps downlink and 5 Mbps uplink. However, there are trade-offs. Dropping receive diversity reduces link budget compared with Cat-1, and Cat-1bis doesn't provide the same building-penetration characteristics as LTE-M. But its biggest advantage isn't speed; it's availability.

Cat-1bis works across existing 4G LTE networks without requiring operators to deploy a special LTE IoT network. Fundamentally, that’s different from LTE-M and NB-IoT, whose coverage depends on whether an operator has deployed and supports those technologies in a particular market.

For a device manufacturer shipping globally, that matters. A device doesn't care that a network technology is strategically important. It cares whether it can connect when it arrives in a market.

Cat-1bis inherits the enormous existing LTE footprint and mature LTE roaming ecosystem. That's a powerful property, and one that shouldn't be dismissed simply because it isn't the newest technology.

The combination to watch: eRedCap and Cat-1bis

Here's where it gets interesting, and it's the part almost nobody is writing about yet.

eRedCap and Cat-1bis occupy roughly the same throughput tier, but they don't depend on the same network technology. eRedCap runs over 5G Standalone (SA). Cat-1bis runs over LTE.

Put both capabilities into the same module, and you get something much more practical:

• eRedCap where 5G SA exists.
• Cat-1bis where it doesn't.

One hardware SKU can take advantage of the newer 5G technology without making the entire deployment dependent on the pace of a 5G SA rollout.

Sequans has already announced its Calliope 3 line pairing 5G eRedCap with LTE Cat-1bis, with samples planned for 2026. Others will follow, as that approach makes a lot of sense.

Because the problem with designing around a new network technology isn't necessarily the technology itself. It's the coverage gap while the network catches up.

For high-volume, lower-throughput devices, eRedCap + Cat-1bis could provide a much more practical migration path to 5G: 5G upside without a coverage cliff.

Where RedCap is actually live

RedCap adoption is moving from specification to commercial deployment. In its April 2026 industry update, the GSA identified 42 operators across 27 countries investing in RedCap, with 14 already offering commercial service. That includes operators in the US, Germany, Japan, Australia, Spain, Singapore, the UAE, and China.

While that's meaningful progress, there's an important detail hidden behind those numbers. Every RedCap deployment has a prerequisite.

The part of RedCap most coverage maps don't tell you

RedCap only works where a carrier has stood up 5G Standalone. Not simply “has 5G coverage," it has 5G SA. That's a critical distinction. A carrier can have extensive 5G coverage while its 5G Standalone footprint remains much smaller. SA deployments are developing at different speeds across countries, operators, and regions.

Which means when someone says:

“We're deploying on RedCap.”

There is another question hiding underneath:

On whose 5G SA network?

And followed by:

Where does that network actually work today?

This is the part that matters when devices leave the lab.

Imagine a smart-grid rollout spanning multiple states. A telematics fleet crossing borders. A medical device that needs to behave consistently in an urban hospital and a rural clinic. A RedCap device tied to a single operator's SA footprint inherits that operator's rollout schedule. If SA coverage hasn't reached the places your devices operate, the problem isn't your RedCap modem. It's your connectivity architecture.

The radio can fall back. Can your connectivity?

A dual-mode module solves an important part of the problem. But hardware fallback isn't the same thing as network flexibility. A modem can support multiple radio technologies. Your connectivity strategy still needs to give that device access to the networks those technologies require.

If your SIM is tied to one operator's footprint and their roaming partners, then the fallback options may be limited by the commercial agreement behind the SIM.

This is why we believe the connectivity strategy needs to move beyond: “which network should we use?”

It should move toward, “What connectivity architecture gives us the most options?”

That’s the problem a modern software-defined connectivity approach solves, bringing multiple cellular carriers, satellite, and NTN, and public network access together into one connectivity platform and one SIM.

That matters for products that don’t live in one network footprint. Because a global device shouldn't have to wait for every market to adopt the same technology at the same time. The device should be able to use the best available connectivity for where it is:

• eRedCap where it’s available.
• Cat-1bis or LTE where it isn’t.
• Satellite where terrestrial coverage disappears.

And ideally, that shouldn’t require a firmware change, a second device SKU, or a new connectivity negotiation every time the network landscape changes. That’s the difference between adopting a radio technology and building a connectivity architecture.

Key questions to ask before choosing RedCap

If you’re evaluating RedCap or planning for eRedCap, don’t stop at peak throughput. Ask your connectivity provider:

1. Does our connectivity strategy tie us to a single carrier’s 5G SA rollout?

   • Or can we access multiple networks as coverage matures at different speeds in different markets?
2. What happens in a market where the 5G tier isn’t available?

   • Does the device have a clean LTE fallback, or does the connectivity strategy create a coverage gap?
3. What covers the places with no usable terrestrial network at all?

   • If the device operates somewhere with no usable cellular network, is there another connectivity path?
4. Who owns the coverage gap problem?

   • If coverage changes six months or two years from now, do we have the flexibility to adapt, or are we locked into the carrier we chose at the beginning?

Those questions are more important than another peak-speed comparison.

Where each cellular IoT tier actually fits

• NB-IoT and LTE-M — low data rates, multi-year battery life, deep indoor penetration, metering and sensing. Operator-deployed, so coverage varies by market. Unchanged by any of this, and not going anywhere.
• LTE Cat-1bis — around 10 Mbps, single receive antenna, and the critical property: works on any existing LTE network with no operator upgrade. The global default for low-throughput devices, and the fallback that makes 5G migration safe.
• eRedCap (Release 18, ecosystem maturing) — the 5G successor to Cat-1 and Cat-1bis at around 10 Mbps. Best deployed alongside Cat-1bis, not instead of it.
• RedCap (Release 17, commercial now) — the 5G successor to LTE Cat-4. Up to roughly 225 Mbps down. Industrial gateways, video-capable monitoring, richer telemetry, mid-tier routers.
• Full 5G NR — broadband and mission-critical low-latency. Everything RedCap deliberately gave up.

The point isn't that one technology wins. The point is that different devices need different layers of connectivity. And the network underneath those devices doesn’t evolve at the same speed.

The bottom line

RedCap is real. It’s commercially available. And it solves a legitimate problem: bringing the cost and complexity of 5G down to a level that makes sense for mid-tier devices. But it isn’t the replacement for every cellular IoT technology that came before it.

And it isn’t an LPWA technology.

The more interesting story is one tier down. eRedCap + Cat-1bis could give the highest-volume, cost-sensitive segment of cellular IoT a practical path into 5G, without forcing devices to wait for 5G SA coverage to become universal.

But even the best dual-mode radio doesn’t solve the connectivity problem by itself. The network landscape is fragmented. Coverage evolves unevenly. Technologies overlap. And a device that works perfectly in one market can encounter a completely different connectivity reality in the next. That's why the radio shouldn’t be the end of the connectivity conversation.

Choose the technology for the device. Build the connectivity architecture for the world.

Don't let a chipset decision quietly become a carrier decision.

FAQ

What is 5G RedCap? RedCap (Reduced Capability), also called NR-Light, is a 3GPP Release 17 specification that simplifies 5G New Radio for non-phone devices. It reduces bandwidth and radio complexity while allowing devices to connect to a 5G core. Its capabilities broadly align with LTE Cat-2, Cat-3, and Cat-4-class devices.

Is RedCap an IoT or low-power technology? No. RedCap includes efficiency improvements compared with full 5G NR, but it was not designed as an LPWA technology. It does not replace NB-IoT or LTE-M for devices requiring multi-year battery life and very low data usage.

Which LTE category does RedCap replace? RedCap is generally considered the 5G successor to LTE Cat-2, Cat-3, and particularly Cat-4-class applications. Typical use cases include industrial gateways, richer telemetry, monitoring, and mid-tier routers.

What is eRedCap? eRedCap, or enhanced RedCap, is the Release 18 evolution of RedCap. It targets roughly 10 Mbps in both directions and is designed for a lower-performance, lower-cost tier of devices, particularly those currently using LTE Cat-1 and Cat-1bis.

What is LTE Cat-1bis? Cat-1bis is a simplified version of LTE Cat-1 that uses a single receive antenna. It provides around 10 Mbps downlink and 5 Mbps uplink with a simpler hardware design and lower bill of materials.

Its biggest advantage is its compatibility with existing LTE networks, making it highly practical for global IoT deployments.

Should I choose eRedCap or Cat-1bis? For many future device designs, the answer may be both. Modules combining eRedCap and Cat-1bis can use 5G where compatible 5G SA networks are available while maintaining LTE connectivity where they aren’t. That provides a migration path to 5G without making the device dependent on the pace of 5G SA deployment.

Do I need 5G Standalone coverage to use RedCap? Yes. RedCap depends on a 5G Standalone core. That means a device can’t simply connect to RedCap anywhere a carrier advertises 5G. Actual RedCap availability depends on where the operator has deployed and enabled 5G SA.

Is RedCap commercially available? Yes. RedCap has moved into commercial deployment, although availability varies significantly by operator and market. According to the GSA’s April 2026 industry update, 42 operators across 27 countries were investing in RedCap, with 14 offering commercial service at that time.

What should I consider before deploying RedCap? Don’t evaluate RedCap on modem specifications alone. Look at the entire connectivity architecture:

• Where is 5G SA actually available?
• What happens when it isn’t?
• Can the device move between networks?
• Is LTE fallback available?
• What happens outside terrestrial coverage?
• Can your connectivity strategy adapt as network availability changes?

The goal isn't simply to put 5G in the device. It’s to make sure the device stays connected wherever it operates.