Offline EV Charging: Why Your CSMS Needs an Edge Plan in 2026

The 4 Deployment Scenarios That Demand Offline Operation

The assumption that EV chargers will always have a strong, low-latency connection is one of the most common and costly design mistakes in 2026. Here are the four scenarios where offline EV charging operations is not optional:

1. Subterranean and structured parking facilities. Underground car parks and reinforced concrete structures block radio frequency signals badly. The walls act as a signal barrier, causing constant connectivity drops. A CSMS that depends on a cloud round-trip for every authorization check will leave drivers stuck and physical kiosks frozen.
   
2. Remote highway corridors and fleet depots. Fast-charging hubs along rural interstates or dedicated logistics depots face the same conditions as oil and gas field equipment: intermittent satellite links, high-volume data that cannot be dropped, and no guarantee of a stable wide-area connection.
   
3. Dense urban microgrids. Heavy cellular coverage doesn't mean clean connectivity. Urban networks deal with spectrum crowding, packet loss, and latency spikes that can last long enough to cause real problems. When a CSMS needs to balance load across solar panels, battery storage, and chargers in real time, waiting on a cloud response is not an option - but offline EV charging is!
   
4. Air-gapped and high-security facilities. Government and military EV fleets operate in environments where the local network is completely cut off from the public internet by design. There is no cloud to call out to. The CSMS must authorize sessions, store transaction data, and run security checks entirely on-site, reconciling records through heavily audited gateways only when the security rules allow it.

Each of these scenarios requires the same underlying answer: a CSMS that treats disconnection as a normal operating mode, not a failure state.

What OCPP Gives You For Free (and What It Doesn't)

OCPP is the standard communication protocol between EV chargers and a central CSMS. The most recent version, OCPP 2.0.1, has added meaningful offline EV charging features.

But understanding exactly where those features stop is what separates a well-designed edge system from one that falls apart the moment the connection drops.

What OCPP handles out of the box:

• Local authorization lists. The central CSMS or offline EV charging OCPP solution can push a list of approved RFID credentials directly to the charger's local memory. When the network drops, the station checks this list locally instead of reaching out to the cloud, keeping known users moving without delay.
• Transaction queuing. When a session ends during an outage, OCPP lets the charger hold the transaction record locally and send it upstream once the connection comes back. No manual intervention needed.
• Smart charging profiles. A CSMS or offline EV charging solution can push power output schedules to a charger in advance. The charger follows these schedules on its own, keeping within panel limits even when cloud-based load balancing goes offline.

Where OCPP falls short:

• No flow control on reconnection. When the connection comes back, OCPP stations push out their queued data as fast as the hardware allows. If hundreds of chargers reconnect at the same time, this creates a data storm that can bring down the central CSMS.
• Hardware-dependent storage. OCPP's store-and-forward behavior is only as good as the hardware it runs on. Volatile memory or low-quality flash storage means a reboot during an outage can permanently wipe transaction records.
• Binary network awareness. OCPP treats the connection as either up or down. It cannot tell the difference between a slow upstream and a dead one, which causes retry loops that lock up threads and drain computing resources on the edge device.
• No peer-to-peer load balancing. A group of disconnected chargers cannot negotiate power distribution among themselves through OCPP alone. An external edge controller has to step in to manage this.

OCPP gets you a solid foundation for short outages with known users. For anything beyond that, the architecture needs to go further.

The 4-State Charger Model: Online, Degraded, Offline, Recovering

A well-designed CSMS does not treat the network as a binary switch. Connections in the real world are rarely perfectly stable or perfectly dead.

A four-state model gives engineering teams a clear, automated set of behaviors for every condition the network throws at the system. Each state has a defined set of behaviors locked in before an outage ever happens. The system moves between states automatically, without waiting for a human to intervene:

1. Online. The edge node and the central CSMS have a clean, low-latency connection. High-resolution telemetry flows upstream in real time, covering voltage readings, phase imbalances, and battery charge gradients. Authorization requests go straight to the cloud for full validation and immediate billing.
   
2. Degraded. High latency, packet loss, or heavy jitter puts the system in a brownout. This state is often more dangerous than a full outage because synchronous systems hang waiting for timeouts that never resolve cleanly. The edge controller cuts its dependence on the cloud right away. Authorization attempts get an aggressive timeout, around 1.5 seconds, and if the cloud doesn't respond in time, the station falls back to its local cache automatically.
   
3. Offline. All wide-area communication is completely cut off. The offline EV charging or edge node operates on its own. Charging sessions carry on without interruption. Authorization comes from local registries and credential caches. All data keeps writing to the local store, and the system completely switches off any retry logic pointed at the cloud, since retrying a dead connection only burns through CPU and memory that the device needs for managing the physical charging session.
   
4. Recovering. Connectivity comes back. This is the most dangerous phase if handled wrong. The edge node does not dump everything upstream at once. Data goes out at a controlled rate that the central CSMS can safely take in, with financial transaction records going first and historical diagnostic telemetry going last. The core system dictates the pace, not the edge node.
   

Store-and-Forward: Design Patterns and Pitfalls

Store-and-forward is the architectural principle that makes the four-state model work in practice. 

The core idea is simple: all data writes to a local durable store first, regardless of whether the network is up or down, and gets forwarded upstream when conditions allow.

Getting this right separates systems that hold up through real outages from ones that lose data or collapse on reconnection.

The four-step pattern that works:

1. Always write locally first. Every telemetry reading, transaction event, and IDS log goes into the local store before anything else. This creates a permanent, append-only record that acts as the single source of truth, completely independent of what the network is doing.
   
2. Forward upstream when the connection is up. In the Online state, the local store acts as a near-instant pass-through. Events write locally and go upstream right away, but the local record always exists as the backup.
   
3. Keep writing during an outage. When the connection drops, the system keeps appending data to the local store without triggering error loops or alert cascades. Available flash memory fills up gradually. The system does not try to reach out upstream at all.
   
4. Catch up at a rate the core can handle. When connectivity returns, the edge node forwards data at the rate the central CSMS sets, not as fast as it physically can. The core pulls data rather than the edge pushing it all at once.

The most common pitfall is relying on retry logic instead of true store-and-forward. Retry logic assumes a temporarily unavailable service will come back shortly. At the edge, a failed connection can mean the network is gone for hours or days.

Continuous retry loops rapidly consume CPU cycles and lock up application threads that should be managing the physical safety of the charging session. 

When connectivity does return, every node retrying at the same time creates a data storm that takes down the central system. The fix is to drop retry logic entirely and let the store-and-forward pattern do the work.‍

Authorization in Offline Mode: Cache, Allowlist, BLE-Assist

The biggest business risk in offline EV charging is revenue loss. If a station cannot verify a user's payment credentials, the operator faces a difficult choice: charge the vehicle for free, or turn the driver away.

In 2026, neither outcome is acceptable. Offline EV charging authorization needs to work across three layers.

Local Cache and Allowlists

The first line of defense is the local credential cache. The edge node keeps an encrypted store of recently authorized users. 

• A fleet driver who charges at the same depot every day has their RFID tag or device ID stored locally. When the network goes down, the station checks the cache, confirms the credential is valid, and authorizes the session based on that stored record.
  
• For larger fleets, the CSMS pushes a full allowlist to edge nodes before any outage occurs. This list holds cryptographically secured credential records that act as the local root of trust.
  
• Private registries on the edge node can verify authorization entirely without reaching out to an external service. The station does not need to know the cloud is offline; it just checks the local registry and makes a decision.

BLE-Assist for Unknown Users

When a driver with no cached credentials shows up at an offline EV charging station, the cache and allowlist don't help. This is where Bluetooth Low Energy (BLE) assist comes in, using the driver's smartphone as a secure bridge between the offline charger and the cloud.

The process works in five steps:

1. The offline EV charger sends out a BLE signal with its disconnected status and a one-time cryptographic code.
2. The driver's EV app picks up the BLE signal and reads the code.
3. The app packages the charger's authorization request and sends it to the central CSMS over the phone's cellular connection.
4. The CSMS checks the user's payment method, signs an authorization token, and sends it back to the phone.
5. The phone passes the signed token back to the charger over BLE. The charger checks the signature against its local root of trust and starts the session.

The driver's phone does the network work that the charger cannot do on its own. Sessions go through cleanly, payment is secured, and no revenue is lost, even during a total wide-area outage.

Recovery and Reconciliation When Connectivity Returns

Getting the connection back is not the end of the process. Reconciliation is a financial, regulatory, and grid management task, and getting it wrong has direct cost consequences.

Rebuilding the Event Timeline

The edge node attaches precise timestamps to every offline EV charging event as it happens.

When data starts moving upstream through the controlled catch-up process, those timestamps let the system apply Time-of-Use billing accurately, even for sessions that took place hours ago.

This is not a nice-to-have; it is a billing accuracy requirement.

• Offline chargers that autonomously cut their power output to stay within local panel limits during the outage must send that telemetry to the central system on reconnection.
  
• If that data doesn't come through, the machine learning models that calculate fair capacity distribution across the charging network will work off incomplete historical data, leading to poor allocation decisions going forward.

Regulatory and Financial Stakes

Accurate reconciliation ties directly to whether operators can claim the funding they are owed. Demand Response programs require operators to prove, with precise timestamped telemetry, that their chargers curtailed output during a grid event. Without that proof, the operator forfeits the DR rebate entirely.

• Cost recovery programs at the state and federal level work the same way. Federal funding for EV charging deployments depends on operators being able to track and report usage accurately.
  
• If telemetry is lost during an offline period, operators cannot demonstrate compliance, and the cost of the deployment shifts back onto local ratepayers.
  
• Programs like DTE Smart Charge require continuous, unbroken records. A store-and-forward architecture that durably holds data through any outage is the only way to meet that requirement.
  
• Financial transaction logs always go upstream first during the catch-up phase. Historical diagnostic telemetry follows after.
  
• The order matters because the financial records are what unlock cost recovery, and those need to be in the central system as quickly as possible once connectivity is restored.

Operator Playbook: Incident Response When a Region Goes Offline

Software architecture handles a lot automatically, but when a full regional outage hits, operations teams need a clear plan that goes beyond what the system does on its own.

Before the incident: pre-fortification

The most effective incident response starts well before anything goes wrong. Three basics cut the risk significantly:

• Multi-factor authentication on every system that touches the CSMS
• Verified access controls for all partners and third-party integrations
• A short, documented incident response playbook that the whole team has practiced

Beyond security, operators need to run a pre-peak systems audit on a regular schedule. This means checking that edge nodes have enough local storage for an extended outage, that allowlists have been pushed to all sites recently, and that BLE-assist is configured and tested at every location. Finding a gap during a routine audit is manageable. Finding it during a regional outage is not.

During the Incident: Detection and Triage

When monitoring systems flag a regional outage, the first job is to work out the scope. Is this a network failure, a hardware issue at the ISP level, or something adversarial? The answer changes the response.

While the edge architecture manages offline EV charging operations automatically, physical site issues still need human attention.

A jammed connector or a broken display cannot be fixed remotely, and during an outage when digital monitoring is unavailable, a single hardware problem at a busy depot can back up traffic quickly.

Having a site contact list ready for every high-traffic location is part of the playbook.

Partnering with Entrans to Implement Offline EV Charging and Other OCPP Requirements in 2026

Moving beyond the just basic offline capabilities of standard OCPP, Entrans implements advanced edge solutions utilizing a four-state charging model: Online, Degraded, Offline, and Recovering

This goes especially considering we implemented this for a leading EV charger manufacturer and helped the company migrate from OCPP 1.6 to OCPP 2.0.1.

Entrans protects operator revenue during outages through localized caching, allowlists, and BLE-assist technologies

In doing this, we guarantee seamless driver experiences and accurate billing even when regions go dark.

Want to see what this would look like? Book a free consultation call!