Upgrading legacy OCPP 1.6J chargers to mTLS: How are you handling the MCU memory constraints?

Has anyone else hit a brick wall trying to get older EV chargers to support OCPP Security Profile 3?
We were looking at modernizing a batch of existing stations running on early Cortex-M3 and M4 microcontrollers. The initial thought was to just push an OTA firmware update to enable mTLS to meet newer cybersecurity regulations. But the physics of these old boards just don't add up.
When you try to run modern TLS 1.2 or 1.3 stacks like mbedTLS, it demands something like 50 to 100 KB of heap memory just to cache the certificate chain and manage the encryption context during the handshake. For these older MCUs, that instantly causes memory overflows. Even when we tried to strip it down, the asymmetric encryption computation took so long that it triggered watchdog timeouts and rebooted the chargers.
Since doing a full "rip and replace" of the hardware is way out of budget, I've been reading up on edge security proxy gateways. The concept is deploying an embedded Linux device locally on the charger's LAN. It essentially does a transparent bi-directional protocol conversion: taking the legacy unencrypted ws:// connection locally and wrapping it into a highly secure wss:// mTLS tunnel to the cloud.
The technical part that caught my eye is how it handles certificate lifecycles. Legacy chargers obviously don't support the ACME protocol. But apparently, this Linux proxy can intercept the SignCertificate.req commands coming from the cloud CSMS, generate the CSR locally, and update the root certificates without the legacy hardware even knowing it's happening.
Has anyone actually deployed a hardware-based OCPP proxy like this in the field? I'm curious if intercepting these payloads introduces any noticeable latency when authorizing a charge.