The FedRAMP Red Team Requirement: What CA-8(2) Actually Asks For

When FedRAMP moved to NIST SP 800-53 Revision 5, it added control CA-8(2) to the Moderate and High baselines. The control text is one sentence: employ red team exercises to simulate attempts by adversaries to compromise organizational systems in accordance with applicable rules of engagement. It was the first time a United States federal program required red teaming at this scale, and the brevity of the requirement is exactly why cloud service providers keep implementing it wrong.

Three misunderstandings account for nearly every problem we see. Providers assume their 3PAO has to run the exercise. They scope it to the authorization boundary. And they treat it as a second penetration test. All three are wrong, and each one produces reviewer questions.

Who is actually allowed to perform it

The exercise may be performed by the 3PAO, by a separate third party that is not a 3PAO, or internally by the provider where it genuinely has the capability and skill sets. What does not change is the attestation path: whoever executes the work, the 3PAO validates and attests to the Red Team Test Plan and the Red Team Test Report during initial SAR testing and during each annual assessment.

That structure creates a choice worth making deliberately. If your 3PAO both runs the exercise and attests to it, you are asking one firm to review its own offensive work. Nothing prohibits it, and plenty of providers do it for convenience. But separating the party that tests from the party that attests is a cleaner evidence posture, and it tends to shorten the conversation with a reviewer who is looking for independence.

It is an enterprise activity, not a boundary activity

This is the scoping mistake that costs the most time. FedRAMP treats red teaming as enterprise focused. It is not confined to the cloud service offering; it tests the organization whose people and processes defend that offering. Corporate identity, corporate endpoints, and personnel are in play.

The logic is sound if you think like an attacker. Nobody attacks a well-hardened production environment from the front when a developer laptop and a phishing email reach the same place with less effort. A red team exercise scoped only to the boundary tests the door an adversary would not use. Providers who scope narrowly to reduce effort generally end up redoing work.

It is not a second penetration test

A penetration test aims to find and exploit as many vulnerabilities as possible within a defined timeframe. A red team exercise is not trying to maximize findings. Its primary objective is to test the organization's detection, defense, and response capability by simulating a real-world attack using tactics, techniques, and procedures currently seen in the wild, and to provide a framework for continuous improvement.

Practically, that means the deliverable looks different. A penetration test report is a ranked list of exposures. A red team report is a narrative of one or more attack paths, with the timeline of what the defenders saw and when. If your red team report reads like a vulnerability scan with better prose, the exercise did not test what the control asks about. We cover the distinction in depth in red team vs penetration testing.

The threat intelligence step people skip

The guidance expects the assessment organization to leverage the provider's own threat intelligence to establish agreed objectives for the engagement. This is a real requirement with a real purpose: it makes the exercise emulate adversaries plausibly interested in your service rather than a generic attacker. It also produces documented objectives, which is what turns an open-ended engagement into something a reviewer can evaluate. Run the session, write down what came out of it, and put it in the plan.

The two deliverables

The organization performing the exercise produces both. The Red Team Test Plan describes the scope, the methodology, the activities slated to be performed, the schedule of those activities, the organizational resources performing the test, and the appropriate authorizations from the provider. The Red Team Test Report summarizes the results.

Write both for someone reading cold who has the authority to send them back. That reader is not looking for elegance; they are checking that the required elements are present and that the work described is plausible for the environment. Thin plans and reports that assume shared context are the most common cause of a return trip.

Where it sits alongside the penetration test

The red team exercise does not replace the annual penetration test, which still has to cover the six mandatory attack vectors defined in the FedRAMP Penetration Test Guidance: External to Corporate including a phishing campaign, External to CSP Target System, Tenant to CSP Management System, Tenant to Tenant, Mobile Application to Target System, and Client-side Application or Agents to Target System. Both obligations are annual, evidenced at initial authorization and revalidated at each annual assessment, on top of monthly scanning.

Red team exercises and static code analysis are not required for LI-SaaS given its lower risk profile. High carries the heaviest overall load, including semiannual incident response plan testing where Moderate is annual.

One scheduling recommendation

Run the exercise early enough in your annual cycle that findings can be remediated and retested before your assessment window. Findings discovered late become POA&M entries, and POA&M entries become questions from agency customers. The exercise is more useful as a forcing function in month three than as a surprise in month eleven.

Where BD Emerson fits

We perform FedRAMP penetration testing across all six attack vectors and CA-8(2) red team exercises as a party independent of your attesting 3PAO, and we write the RTTP and RTTR to be validated rather than rewritten. Our FedRAMP offensive testing service coordinates with the broader red teaming practice and with FedRAMP advisory, so findings arrive already mapped to the controls they affect.