RED cybersecurity is easy to describe and hard to deliver. On paper, it looks like a certification task: add TLS, lock down a few interfaces, write the docs, pass testing. In real products, it behaves like a forced upgrade to the system’s design, because the security requirements show up as RAM, flash, protocol behavior, and supportability.
We just went through this with a customer where the product is about three years in the market and runs ThreadX. The team believed TLS support was already in place and it would be medium effort. Instead the effort still took about 16 weeks with roughly 3.5 engineers (about 56 engineer-weeks), because the requirements overwhelmed a system that was not sized for them.

Where the effort really went
The surprises were not security theory. The surprises were the things we had to create, or work around, because the secure version either did not exist for the platform or did not fit inside the product’s existing resource budgets.

Certificates became a first-class feature
TLS often gets described as “encryption,” but a major time sink was certificates. Certificates have to be stored, parsed, validated, and handled cleanly when they are expired, wrong, missing, or replaced. That behavior also has to be predictable in the field and diagnosable by support, which is harder than it sounds when you are doing it on a device with tight memory.

TLS changed the memory math
Once TLS is real, packet handling and buffering stop being the same problem they were before. Handshakes come in bursts, encrypted records add overhead, and working buffers grow in places that previously felt “safe.” In our case, that growth pushed the system out of RAM, so we reduced buffers, lowered limits, and reworked flows to keep the product stable under load with TLS enabled.

FTPS did not exist in a usable form, so we built it
The product had FTP and it worked, but there was no secure variant we could drop in and trust. The requirement became: add FTPS that behaves like a product feature, not a demo. That dragged in session handling, credential handling, certificate behavior, timeouts, retries, error recovery, and tests, because secure transfers do not fail in neat ways when customers are using them for real work.

Flash limits showed up right after RAM limits
Certificate logic, crypto libraries, and protocol glue add up quickly, and we hit flash ceilings soon after we hit RAM ceilings. Making room meant trimming and reshaping parts of the firmware that had nothing to do with “compliance” on the surface, which is why these projects surprise schedules: security does not sit on top of the product, it competes with the product for the same fixed resources.

What this means for CTOs, CFOs, and VPs of Engineering
The cost is rarely the test fee; the cost is the redesign pressure you absorb once security becomes non-optional. A product can be only a few years old and still be unprepared, because it was designed for a different set of constraints and a different definition of “good enough.”

Action items to reduce schedule and budget risk
Before you jump in, run a short fit check before you promise dates. List every network-facing feature and name the secure equivalent you will actually ship; Do a real gap analysis and anything without a clear, proven secure path should be planned as new development.
Treat certificate handling as real engineering, not a library checkbox. Decide how certificates are provisioned, stored, validated, updated, and debugged, then plan memory for it and measure RAM/flash with TLS and FTPS enabled using production-like settings.
Write scope boundaries in plain language. If secure update and rollback is out of scope, document what that means for long-term maintenance so nobody is surprised later.

RED retrofit reality check
If you suspect your product was not sized for modern security overhead, the fastest way to control cost is to find the breaking points early and decide whether you are retrofitting or redesigning. For a free assessment Book a call