AWS FedRAMP Inheritance: Mapping Shared Responsibility to NIST 800-53

An AWS FedRAMP inheritance strategy that maps to the Risk Management Framework will not help your assessor, because the assessor is not reading your RMF phase. They are reading a control, and asking one question: who implements this, you or the platform. Map your inheritance to NIST SP 800-53 control by control, and that question answers itself. Map it to the RMF lifecycle, and you have documented a process that belongs to the agency rather than to you.

That distinction is the difference between an inheritance strategy that survives assessment and one that generates findings. This guide covers what AWS FedRAMP inheritance actually transfers, which control families move and which do not, how the Certification Classes introduced under the Consolidated Rules for 2026 (CR26) changed the inheritance chain, and where inheritance stops helping entirely, which is defense work.

What AWS FedRAMP Inheritance Actually Is

FedRAMP’s central value is reuse. When a cloud service offering has been independently assessed and certified, the security work underneath it does not have to be redone by every customer building on top. Inheritance is the mechanism by which that reuse reaches you.

The Shared Responsibility Model

The AWS shared responsibility model splits security duties in two. AWS is responsible for security of the cloud: the hardware, the software, the networking, and the facilities that run its services. The customer is responsible for security in the cloud: their content, their applications, their identity configuration, and their data.

Under FedRAMP that split resolves into three control dispositions.

Inherited controls are implemented entirely by the platform. Physical and environmental protections are the clearest example. You do not implement them, you document that you inherit them.

Shared controls apply to both layers in different ways. The platform patches its infrastructure; you patch your guest operating systems. The platform maintains its network devices; you configure your application’s network exposure.

Customer controls belong to you alone. Application-level security, your data handling, and the way you actually configure the services you consume.

Inheritance Does Not Make You Compliant

This is the sentence most vendors leave out. A service does not become FedRAMP compliant simply by running on FedRAMP Certified infrastructure. Each component in your stack requires its own treatment, either through a documented inheritance relationship or through your own implementation. The platform’s certification is a prerequisite, not a substitute.

Inheritance also depends on a documented link between the providing system, which is AWS, and the receiving system, which is your environment. That link has to be recorded, dated, and defensible. Elevate’s primer on what FedRAMP is and what it covers sets the context.

Map AWS FedRAMP Inheritance to NIST SP 800-53, Not to the RMF

Most inheritance guidance walks you through the six phases of the Risk Management Framework: prepare, categorize, select, implement, assess, authorize, monitor. It reads well and it is the wrong tool for this job.

The RMF Belongs to the Agency

The Risk Management Framework is the process a federal agency runs to authorize a system it operates. It is how an Authorizing Official decides to issue an Authority to Operate. A cloud service provider does not run the RMF. It produces a certification package, which FedRAMP reviews and certifies, and which an agency then uses as an input to its own RMF process.

Structuring your inheritance strategy around RMF phases therefore documents someone else’s workflow. Worse, it produces an artifact organized by phase when every reader who matters needs it organized by control.

Your Assessor Reads Controls, Not Phases

An independent assessor evaluating your service opens the control catalog. For each applicable control they ask whether it is implemented, by whom, and with what evidence. A responsibility assignment mapped to NIST SP 800-53 answers that directly and tells the assessor exactly where responsibility sits between the provider and the client. A responsibility assignment mapped to RMF phases forces them to translate.

There is a second reason the control mapping wins under CR26. The Customer Responsibility Matrix that AWS publishes is organized by control. The FedRAMP baselines are organized by control. Your certification package is organized by control. Every artifact in the chain already speaks 800-53. Elevate’s primer on NIST SP 800-53 Rev 5 covers the catalog you are mapping to.

Which Control Families Transfer

The table below describes the typical disposition on the Rev5 path. Confirm every row against the current Customer Responsibility Matrix for the specific services you consume, because dispositions vary by service and change over time.

Note the shape of the table. The families that transfer cleanly are the ones furthest from your application. The families that do not transfer at all are the ones that describe how your organization behaves. No platform can inherit your incident response process for you.

Hybrid Controls Are Where Assessments Fail

Take AC-2, account management. The platform manages accounts for the underlying operating system and hypervisor components. You manage application user accounts. Both statements are true, and a control description that asserts only one of them is a finding waiting to happen.

The failure mode is symmetrical and expensive: both parties assume the other implements a requirement, and neither does. Read each control element rather than each control label. The Customer Responsibility Matrix goes beyond a simple customer-or-AWS tag and specifies which aspects of a control belong to whom. That specificity is the entire point of the document.

Certification Classes Changed the Inheritance Chain

CR26 retired the Low, Moderate, and High impact level labels as names for FedRAMP certification baselines and replaced them with Certification Classes A through D. Class B covers the former Low and LI-SaaS baselines, Class C the former Moderate, and Class D the former High. On the Rev5 path Class D carries roughly 410 controls across the 20 NIST SP 800-53 control families.

The Mismatch Trap, Updated

The classic inheritance failure was a system categorized High running on infrastructure authorized at Moderate. The inheritance chain breaks, compensating controls appear, and the savings evaporate.

Under CR26 there are now two mismatches to avoid, not one.

The first is the inheritance mismatch. Your Certification Class cannot exceed what the underlying platform’s Class supports. If you pursue Class D on infrastructure certified at Class C, you have to implement the difference yourself, and you have paid for inheritance you cannot use.

The second is the adequacy mismatch, and it is newer. FedRAMP states that a Certification Class describes the depth and frequency of assurance data a provider supplies, not how secure a service is, and it instructs agencies not to treat a Class as a one for one replacement for an impact level. FIPS 199 impact levels still exist, and agencies still categorize their own systems as low, moderate, or high. Your Class informs the agency’s decision. It does not make it. Elevate’s guide to FedRAMP Classes and controls covers the mapping, and its breakdown of CR26 covers the governing dates.

Verify Platform Status, Do Not Assume It

Confirm the current certification status and Class of every AWS region and service you depend on, in the FedRAMP Marketplace and in AWS’s own Services in Scope documentation. Two reasons this article publishes no service counts and no status claims.

Authorization status changes without notice, and a status printed in an article ages badly. More importantly, CR26 changed the designations the Marketplace displays. A status claim written before mid-2026 may describe a designation that no longer exists, including any reference to a Joint Authorization Board Provisional Authority to Operate. The JAB was dissolved and the P-ATO is not an available outcome, so any platform certification described that way needs to be re-verified rather than repeated. Elevate’s GovCloud strategy guide for CTOs covers region selection in depth.

Inheritance on the FedRAMP 20x Path

One structural note. On Rev5, inheritance is expressed control by control through the responsibility matrix. On the FedRAMP 20x path there is no control baseline to inherit against, because assurance is demonstrated through Key Security Indicators and machine-readable evidence rather than a documented control set. Building on certified infrastructure remains a prerequisite, but the artifact that evidences it is different. Confirm with your assessor how inheritance is expected to be evidenced before you build the documentation.

How to Use the AWS Customer Responsibility Matrix

The Customer Responsibility Matrix is the document that turns a legal and technical boundary into NIST 800-53 terms. Without it, control implementation is guesswork.

Where to Get It

The matrix is available through AWS Artifact as an attachment to the AWS FedRAMP Customer Package. Retrieve it early, before you design anything, because the answer to “what is already done” determines what you build.

AWS also publishes Customer Compliance Guides mapping its services to NIST SP 800-53 Rev 5 and other frameworks. Check AWS Artifact for the current version rather than citing a version number from an article, including this one, since these documents are revised.

How to Read It

The matrix splits responsibility three ways: controls the platform fully implements, controls the customer fully manages, and controls both parties implement in part. On the Rev5 path this information historically lived in the CIS/CRM workbook attached to the System Security Plan.

Note that the SSP is now a legacy artifact. CR26 replaced FedRAMP’s template set with JSON schemas and moved implementation detail into the Security Decision Record. The SSP remains available and some agencies, notably within the Department of Defense, still require it, but the responsibility mapping needs to travel into whichever artifact your certification package actually uses.

How to Avoid Control Gaps

Three practices prevent the gaps that produce findings.

Document each inheritance relationship explicitly, naming the specific AWS service that provides each inherited control, with the date of the platform’s certification.

Address every element of every control rather than every control label. Partial implementation of a control with multiple parts is a finding, not a partial credit.

Reconcile your package documentation against the matrix before an assessor does. Inconsistency between what you claim to implement and what the platform says you must implement is the single most common source of avoidable findings. Defining the boundary properly is the prerequisite, and Elevate’s guidance on scoping an enclave and on scoping fundamentals applies directly.

Where Inheritance Stops Helping: Defense Work

Inheritance guidance routinely promises assessment reciprocity, on the logic that the Department of Defense defines reciprocity as an agreement among participating organizations to accept each other’s security assessments. That definition exists. The practice largely does not.

Reciprocity Is Defined, Not Practiced

DoD may define reciprocity, but it does not generally accept other certifications in place of its own. The exception has been FedRAMP Moderate equivalency, and even that is now uncertain under the CR26 changes. Building a defense go-to-market plan on the assumption that a civilian certification will be accepted is a planning error, not a compliance shortcut.

The practical consequence is that an AWS FedRAMP inheritance strategy that materially reduces your civilian assessment scope may reduce your defense scope very little. Budget those as two efforts.

DoD Requirements Are Stricter

Cloud services supporting DoD contractors have been required to meet security requirements equivalent to the FedRAMP Moderate baseline, and what “equivalent” means has been contested for years. DoD subsequently tightened the standard, requiring full compliance with the applicable security control baseline as verified by a FedRAMP recognized independent assessor, and DoD does not accept plans of action and milestones from third-party organizations the way civilian agencies do.

Documentation obligations follow. Organizations using cloud services under a moderate equivalency claim must provide their assessor with a customer responsibility matrix, along with the corresponding system security documentation, assessment plan, assessment report, and plan of action and milestones. Responsibility for reporting compromises and confirming that providers follow incident response plans sits with the contractor, not the cloud provider. Elevate’s CMMC scoping checklist for CUI covers the boundary implications.

Confirm the current requirement with counsel or with your assessor before relying on any equivalency claim. This area moved recently and is moving again.

Common Pitfalls That Break Inheritance

A Broken Chain

AWS FedRAMP inheritance collapses the moment you categorize your system above what your hosting infrastructure supports. Categorizing above what the platform supports breaks inheritance and forces compensating controls. Under CR26 this means confirming your target Certification Class against the platform’s Class, not against an impact level label that no longer names a FedRAMP baseline.

Missed Parameters

The move to Rev5 revised control parameters as well as adding controls. Teams commonly review the new controls and overlook the updated parameter values inside controls they already implement. Those parameters are still being revised: RFC-0027 through RFC-0030 are updating Rev5 baseline parameters as part of CR26, five control families per RFC. Pull current values from the applicable baseline document rather than from documentation written a year ago.

Weak Provider Documentation

Inheritance without a detailed responsibility matrix is an assertion, not a control implementation. If a provider cannot supply a matrix specifying control elements rather than control labels, you are carrying implementation risk you have not priced.

What Inheritance Actually Saves

Every published percentage on AWS FedRAMP savings is a vendor estimate, and the ones in circulation contradict each other. There is no reliable figure for how much inheritance reduces cost, timeline, or control burden, and this article will not invent one.

Two things are known. The Government Accountability Office reported to Congress in January 2024 that FedRAMP cost estimates from agencies and providers ranged from tens of thousands to millions of dollars, that actual cost data were limited, and that participants counted different things. That is the ceiling on what anyone can honestly claim about FedRAMP economics.

And structurally, inherited controls are reviewed as inherited rather than reassessed inside your boundary. Your assessor tests what you implement. That is not a percentage, it is a mechanism, and it is the reason a startup on certified infrastructure and a startup running its own hardware are not doing the same project even when they hold the same Class.

The savings are real. The number is not knowable in advance, which is exactly why the scoping decisions matter more than the tooling decisions. To map your inheritance strategy against your actual architecture, talk to an Elevate advisor.

Conclusion

AWS FedRAMP inheritance is a documentation discipline before it is a cost saving. Map your responsibility assignment to NIST SP 800-53 control by control, because that is what the assessor reads and what every artifact in the chain already speaks. Reserve the Risk Management Framework for the agency that runs it.

Confirm your Certification Class against the platform’s Class rather than against an impact level label FedRAMP no longer uses for its baselines. Pull the Customer Responsibility Matrix before you design, read control elements rather than control labels, and reconcile your package against the matrix before an assessor does it for you. And treat defense work as a separate effort, because reciprocity is defined more often than it is practiced.

Elevate Consult works as an advisor rather than an assessor, which keeps that guidance independent of the firm that will eventually test your controls. Its FedRAMP advisory team maps type, path, Class, and boundary before budget is committed. To build an inheritance strategy that survives assessment, talk to an Elevate advisor.

Key Takeaways

AWS FedRAMP inheritance transfers real work, and it fails in predictable places.

Map to NIST 800-53, not to the RMF. The Risk Management Framework is the process an agency runs to issue an ATO. Your assessor reads controls and asks who implements each one. Every artifact in the chain, including the Customer Responsibility Matrix, is organized by control.

Inheritance does not make you compliant. A service running on FedRAMP Certified infrastructure is not thereby certified. Each component needs a documented inheritance relationship or your own implementation.

Physical, environmental, and maintenance controls transfer. Incident response and planning do not. The families that move are the ones furthest from your application. No platform inherits your organization’s behavior.

Hybrid controls are where assessments fail. Read control elements, not control labels. Both parties assuming the other implements a requirement is the most expensive symmetrical error in the process.

Classes replaced impact levels, and there are now two mismatches to avoid. Your Class cannot exceed the platform’s Class. And a Class is an assurance commitment, not an agency’s FIPS 199 categorization, which still exists.

The JAB and the P-ATO are retired. Any platform certification still described as a JAB P-ATO needs re-verification, not repetition.

Defense work is a separate effort. DoD defines reciprocity but does not generally accept other certifications in place of its own, and FedRAMP Moderate equivalency is uncertain under CR26.

FAQs

Q1. What are inherited controls in the AWS shared responsibility model?

Inherited controls are security requirements implemented entirely by the platform, which the customer documents rather than implements. Physical and environmental protection and maintenance are the clearest examples. Inheritance depends on a documented relationship between the providing system, meaning AWS, and the receiving system, meaning your environment. Inherited controls are reviewed as inherited rather than reassessed inside your authorization boundary, so your independent assessor tests only what you implement.

Q2. Should AWS FedRAMP inheritance be mapped to the RMF or to NIST 800-53?

To NIST SP 800-53, control by control. The Risk Management Framework is the process a federal agency runs to authorize a system it operates and to issue an Authority to Operate. A cloud service provider does not run the RMF. An assessor reviewing your service opens the control catalog and asks, for each control, who implements it and with what evidence. A responsibility assignment mapped to 800-53 answers that directly. The Customer Responsibility Matrix, the FedRAMP baselines, and your certification package are all organized by control.

Q3. Does running on FedRAMP Certified AWS infrastructure make a service compliant?

No. A service does not become FedRAMP compliant by running on certified infrastructure. Every component in your stack requires either a documented inheritance relationship or your own implementation. The platform’s certification is a prerequisite, not a substitute. Application-layer families such as incident response, planning, and assessment and monitoring do not transfer at all.

Q4. How did CR26 change the inheritance chain?

CR26 replaced the FIPS 199 impact level labels with Certification Classes A through D as the names of FedRAMP baselines. Two mismatches now matter. Your Certification Class cannot exceed the Class supported by the underlying platform, or you implement the difference yourself. And a Class describes the depth and frequency of assurance data a provider supplies, not how secure a service is, so it does not replace the FIPS 199 categorization an agency performs on its own system. The Joint Authorization Board and its Provisional Authority to Operate were also retired.

Q5. Does inheritance help with Department of Defense work?

Much less than civilian work. DoD defines reciprocity as an agreement among participating organizations to accept each other’s security assessments, but it does not generally accept other certifications in place of its own. The exception has been FedRAMP Moderate equivalency, which is uncertain under the CR26 changes. DoD also does not accept plans of action and milestones from third-party organizations the way civilian agencies do. Budget defense and civilian efforts separately.