Compensating Controls for Legacy Systems: Accepting Cryptographic Risk With Evidence

Three Treatments, One Owner

Every open finding gets one of three treatments. The question an assessor asks is who chose it, so the choice belongs to a named person who owns the business risk of that system.

• Remediate: change, upgrade, or replace the system, with a dated plan.
• Mitigate: put controls around the system that cut the likelihood or the impact of the weakness while it stays in service.
• Accept: record that the residual risk is understood and approved, with the controls, the owner, and a review date.

Mitigation and acceptance usually travel together. Compensating controls reduce the risk, and the owner then accepts what remains.

First, Confirm It Can't Change

An exception record that says "can't change" gets read closely, so check the claim before you write it.

• Vendor options. Look for a firmware release, a configuration setting, or a supported cipher list the vendor documents. Ask in writing and keep the answer.
• Client inventory. Find out which clients still need the weak setting. Sometimes one old client is the only reason it stays on, and that client can be upgraded or retired.
• A modern front door. A proxy or load balancer that speaks current TLS to clients and reaches the old system over a short internal hop often closes the finding on the public side. The legacy system keeps its limits, and the exposure shrinks to the internal hop.

When the answer is still no, the constraint usually takes one of four shapes. The vendor has ended support. A fix exists, but deploying it needs an outage window, field work, or retesting that can't happen soon. Turning off the weak setting would cut off a client or integration that speaks nothing else. Or changing the configuration would void vendor support or a certified build.

I think the distinction that matters most here is between "can't" and "not yet." A fix that exists but can't deploy yet gets a remediation plan with a date, and compensating controls cover the gap until it lands. Acceptance is for the systems with no fix at all.

NIST SP 800-53 draws the same line. Accepting a risk is a risk response under RA-7, recorded with its justification. A mitigation that can't finish right away goes into the plan of action and milestones (CA-5) with a milestone date, and a component the vendor no longer supports falls under SA-22: replace it, or arrange support from another source. FedRAMP has a name for the middle case. A vendor dependency is a fix that waits on the vendor: it stays open, you check with the vendor at least once a month, and a High one has to come down to Moderate through compensating controls within 30 days.

Compensating Controls That Carry Weight

A compensating control earns its place by reducing the specific risk the weak setting creates. For weak transport encryption, that means keeping the attacker from reaching the traffic, shortening what any one key protects, and noticing when something goes wrong.

Pick the controls that fit the finding. A system with a weak cipher and an internet-facing listener needs isolation first. A system that sits on a locked-down segment needs the monitoring and the limits.

Write the Record

At a NERC/FERC CIP grid operator, this was my job as the vulnerability SME: cipher-suite, protocol, key-exchange, and certificate findings, remediated where the systems allowed and accepted with documented compensating controls where legacy hardware couldn't. For each one I recommended the treatment, wrote the justification and the controls, and kept the evidence current until the finding closed.

One page per exception works well. An assessor reads it to answer three questions: why can't this be fixed, what protects the system now, and who is accountable. These fields cover them.

1. The asset and the finding. The system by name and address, and the exact scanner string, such as "SWEET32 / 3DES cipher suites enabled".
2. The constraint. Why the direct fix isn't available, with the vendor's written answer attached.
3. The compensating controls. Each control, what it reduces, and where the evidence lives.
4. The residual risk. What remains after the controls, in a sentence the owner can read and sign.
5. The owner and approval. A named person with authority over the system's business risk, and the date they signed.
6. The dates. A review date, and a replacement or retirement date.

What I Weighed Before Recommending Acceptance

The hard part was the reasoning.

Before I recommended accepting a finding, I had to be sure no remediation path existed. I read the vendor's release notes, advisories, and configuration guides for a fixed version or a setting. I opened a support case so the answer came back in writing. Where I could, I tested the change to see what broke, and I traced which client, peer, or integration still needed the weak setting and whether that side could move.

Then came the judgment: accept the risk as it stood, or mitigate it further first. Exposure decided much of that call. The same weak cipher on an isolated network segment with no internet path carries a different risk from the same cipher on a public listener, and getting the call right means knowing how the attack works and what it needs to reach the traffic.

What the Assessor Needs to See

An assessor wants proof that a person decided, that controls are running today, and that the decision has an end date. The frameworks use different words for the same page.

• NIST Cybersecurity Framework 2.0: the record answers two outcomes. ID.RA-06 expects risk responses to be chosen, planned, tracked, and communicated, and ID.RA-07 expects exceptions to be assessed for risk impact, recorded, and tracked.
• NIST SP 800-53: a weak cipher left in place is a documented, approved deviation from your configuration settings (CM-6). Accepting it is a risk response (RA-7), work still in progress is a plan of action and milestones entry (CA-5), and an unsupported component falls under SA-22. The transport requirements involved are SC-8 and SC-13.
• NERC CIP and FedRAMP: each has its own form for this page, and the same fields fill it. FedRAMP adds one hard rule: it never approves an operational requirement for a High finding, so a High has to be mitigated first.

Before you hand the record over, read it for five gaps: no end date, a single firewall standing in as the whole control set, an owner listed as "IT" with no person named, controls described without evidence attached, or one exception covering a class of assets where it should name a system. Each takes a few minutes to close.

Where It Lands in the Risk Register

The exception gets one row in your risk register: the asset, the finding, the treatment, the compensating controls, the owner, the review date, and the replacement date. The review date puts it on a calendar, so the exception expires and gets a fresh decision instead of renewing by itself. At each review, check that every control is still running and attach fresh evidence. If your scanner supports exceptions, give the suppression the same end date, so the finding returns to the report when the review comes due. Every accepted finding stays visible until the replacement closes it.

Why This Is Cryptography Work

Each legacy cipher you can't remove is an item in your cryptographic inventory, with a name, an owner, and an expiry date.

The SWEET32 / 3DES finding walks through the fix and the exception path for one scanner string. We close encryption findings and write the records for the ones that stay open through Vulnerability Remediation, and PQC Readiness builds the inventory those records belong in.

This is the work FEDLIN was built around: find it, fix it, or document why you can't.

Start With One System

Pick the system the scan flags most often. Send its vendor one written question today: is there a firmware release or a setting that removes the weak cipher or protocol? The answer, whichever way it comes back, is the first line of the record.

Compensating Controls: Common Questions