Presented by Carahsoft

For much of its history, FedRAMP has asked cloud service providers to prove that required security controls were in place. Pete Waterman and Ryan Hoesing want the program’s next generation to answer a more meaningful question: How does the provider actually perform when the system changes or a threat appears?

Waterman, Director of FedRAMP at the General Services Administration, and Hoesing, the program’s Chief of Staff, say FedRAMP 20x is designed to move the government away from point-in-time assessments and toward persistent, operational assurance.

The shift reflects a technology environment in which systems, vulnerabilities and attacks are moving faster than traditional compliance processes can respond.

“Companies are ready to rethink the way that they’re going about security,” Waterman said. Historically, compliance has often functioned as a separate organization, removed from the engineering and product teams responsible for building and operating the technology.

That separation is becoming untenable.

Waterman pointed to the emergence of AI-enabled and autonomous systems capable of acting at machine speed. In that environment, organizations cannot rely on security processes that take weeks or months to produce an answer.

“We need compliance built in with engineering,” he said, “and we need everyone moving fast together.”

The government’s previous model frequently focused on whether a provider had implemented a required control. Hoesing offered multifactor authentication as an example. An assessor might ask whether the setting was enabled, receive a screenshot and accept that evidence as proof.

The screenshot showed that multifactor authentication was turned on at one moment during the audit. It did not show how consistently the control worked across actual daily activity.

The more useful question, Hoesing said, is what percentage of logins follow the required multifactor process each day. That creates continuing visibility into the organization’s real security posture.

“It’s the difference between a checklist that we’re talking about at a point in time versus actually having real-time intelligence,” he said.

FedRAMP 20x also seeks to make security evidence easier for agencies and automated tools to consume. Much of the program’s information has traditionally been stored in spreadsheets and documents. Although those formats may contain the necessary data, agencies often must devote significant human effort to reviewing and interpreting them.

Moving toward machine-readable formats would allow governance, risk and compliance tools to ingest information directly. Instead of waiting for people to read hundreds of pages, agencies could evaluate evidence through automated processes and focus human attention on the highest-risk issues.

The concept of persistent validation sits at the center of this model.

Persistent does not mean that every control must be tested every second. The appropriate frequency depends on the service, its impact level, the underlying risk and the agency’s needs. A provider might decide that a particular check should occur every four hours or every 12 hours. The agency using the product can then determine whether that schedule provides sufficient assurance.

But time is not the only possible trigger.

Waterman said a validation cycle might begin when software is deployed, when a configuration changes or when telemetry indicates suspicious activity.

“Time is important,” he said, but “time doesn’t necessarily matter if nothing changes.”

He compared the concept to monitoring a door. If the door remains closed, repeatedly verifying who entered may accomplish little. When the door opens, the system should determine whether the action was legitimate.

That event-driven approach can make security both more effective and more efficient. Automation concentrates attention on meaningful changes instead of forcing organizations to repeat the same manual checks according to a fixed calendar.

FedRAMP leaders also want agencies to look more closely at how providers respond in practice.

A written incident-response plan tells the government what a company intends to do. Operational data can show what the company has done over the previous six months. One provider may regularly remediate vulnerabilities within hours, while another takes several days.

“I don’t want my information out on the internet for three days,” Waterman said.

Those response metrics could become a more useful measure of trust than the existence of a document stating that the provider has a plan.

The new model also recognizes that federal information does not all carry the same level of risk. Some agency systems handle sensitive health, financial or national security data. Others support public information and activities that would create relatively little harm if exposed.

Waterman argues that agencies should be able to select more affordable and accessible capabilities for lower-risk uses rather than applying the most demanding security approach to every workload.

“The vast majority of the work that we do on a day-to-day basis is actually subject to FOIA,” he said. “It can be public at any time.”

That does not mean the government should be careless. It means agencies should apply the risk management framework as intended, matching security protections to the information and mission involved.

FedRAMP certification also does not eliminate the agency’s responsibility to review a product.

Hoesing said reciprocity is sometimes misunderstood as permission to adopt a certified product without examining its security package. In reality, FedRAMP creates reusable evidence that an agency can use to make its own risk determination.

There have been cases in which agencies deployed a cloud service without confirming that they were using the FedRAMP-certified version of the product. That is not a failure of reciprocity. It is a failure to perform the agency’s part of the risk-management process.

“We need agencies to be investing resources and time into making these risk decisions,” Hoesing said.

Changing that behavior will require more than a new technical framework. Agencies need qualified personnel, leadership support and incentives to move beyond familiar processes. Directives and regulations can establish expectations, but employees must also feel empowered to act when a vulnerability appears.

The threat environment makes that urgency difficult to ignore. Waterman described a future in which AI-enabled systems can scan and attack internet-facing technology at enormous scale. Vulnerabilities that once required a person to identify and exploit could become targets for automated adversaries.

Government security processes must be able to operate at “the speed of autonomous systems.”

FedRAMP can provide the structure for that transformation, but Waterman and Hoesing emphasized that trust will emerge only when every participant fulfills its role. FedRAMP must establish the framework. Providers must supply credible assurance. Agencies must examine the evidence and make informed decisions.

“FedRAMP provides the framework,” Waterman said, “but it’s always going to be on the cloud service provider to provide the assurance.”

The program’s success may become visible when the first agencies adopt FedRAMP 20x systems and begin sharing their experience with others. Early agency confidence helped accelerate previous FedRAMP models, and Hoesing expects a similar pattern this time.