One authorization. Multiple boundaries.
You've already achieved ATO. Now another agency wants you to start over. Reciprocity should eliminate redundant assessments, but inconsistent implementation means organizations repeat 80% of authorization work for each new boundary. Thalorin automates gap analysis, maps control deltas, and generates the artifacts required for reciprocity acceptance.
Policy mandates reciprocity. Reality resists.
The March 2024 Deputy SecDef memorandum mandates reciprocity implementation “except when cybersecurity risk is proven too great”—the strongest policy push to date. DoDI 8510.01 establishes reciprocity as the default for systems already deployed in DoD.
Yet DoD IG audits reveal inconsistent implementation: some Components leverage reciprocity effectively while others don't consider it a priority. The gap between policy and practice costs organizations months of redundant work.
Lack of Standardization
DoDI 8510.01 explicitly does not dictate artifact formats. Authorization packages vary wildly between organizations, making comparison and acceptance difficult.
Different Risk Tolerances
What's adequate encryption at one agency may fail at another. AOs exercise discretion differently, and risk acceptance varies by mission context.
Tool Fragmentation
eMASS, Xacta, CSAM—each system of record has customized workflows. Data exchange between tools requires manual translation.
Trust Gaps
Receiving AOs can refuse reciprocity for insufficient content or excessive enclave risk. Without standardized quality measures, rejection triggers full reassessment.
Know your pathway
Reciprocity isn't one-size-fits-all. FedRAMP to DoD follows different rules than interagency DoD or coalition partner acceptance. Each pathway has specific control deltas, documentation requirements, and approval workflows. Thalorin maps your existing authorization to target boundaries and identifies exactly what's needed.
Direct reciprocity. FedRAMP Moderate authorization accepted for IL2 workloads with minimal additional documentation.
See exactly what's missing
Reciprocity fails when receiving organizations discover gaps late in the process. Thalorin performs automated gap analysis the moment you select a target boundary—comparing your existing control implementations against target requirements, identifying missing evidence, and flagging controls that need additional documentation or implementation work.
- MP-4: Media Storage
- MP-5: Media Transport
- SC-28: Protection of Information at Rest
- +9 more
The five artifacts that matter
CNSSI 1254 defines the RMF core documents forming the Body of Evidence necessary for reciprocity consideration. Receiving AOs evaluate these artifacts to determine if existing authorization demonstrates sufficient rigor. Thalorin ensures your BoE meets the quality bar for acceptance.
System Security Plan (SSP)
The foundational document describing system boundaries, control implementations, and security architecture. Must be current, complete, and consistent with assessed state.
Security Assessment Report (SAR)
Documents assessment methodology, findings, and recommendations from the Security Control Assessor. Demonstrates independent validation of control effectiveness.
Risk Assessment Report (RAR)
Identifies threats, vulnerabilities, and risks to the system. Quantifies likelihood and impact. Documents risk mitigation strategies.
Plan of Action & Milestones (POA&M)
Tracks known weaknesses and remediation plans. Shows organizational commitment to addressing gaps.
Authorization Decision Document
The formal ATO letter from the authorizing official accepting residual risk. Establishes authorization boundary and conditions.
Reciprocity search across all eMASS instances
eMASS provides designated users the ability to search across all eMASS instances for existing authorizations. When a system already holds DoD authorization, the receiving Component can locate the authorization record, review the Body of Evidence, and make a reciprocity determination without requiring the system owner to resubmit documentation. Thalorin integrates with eMASS to streamline this workflow.
Reciprocity Search
Query all eMASS instances to locate existing authorizations for a system or CSP. View authorization status, AO contact, and BoE summary.
Package Export
Generate eMASS-compatible XML exports of your authorization package. Formatting aligned with eMASS import specifications.
Delta Documentation
When reciprocity requires additional controls, Thalorin generates the delta package formatted for eMASS entry—minimizing manual data entry.
Status Tracking
Monitor reciprocity request status across multiple receiving organizations. Dashboard view of pending decisions and required actions.
The 38 controls between FedRAMP and IL4
FedRAMP Moderate provides a strong foundation, but DoD IL4 requires additional controls for handling Controlled Unclassified Information. These FedRAMP+ requirements fall into two categories: Conditional (C) controls that apply based on system characteristics, and Conditional Enhancement (CE) controls that strengthen existing FedRAMP requirements.
Access Control (AC)
Strengthened account management, session controls, and privilege restrictions for CUI environments.
- AC-2(5): Inactivity Logout
- AC-2(13): Disable High-Risk Accounts
- AC-11(1): Pattern-Hiding Displays
Audit (AU)
Extended logging, non-repudiation, and audit trail requirements for accountability.
- AU-10: Non-repudiation
- AU-12(1): System-wide Audit Trail
- AU-12(3): Authorized Changes Only
Identification & Authentication (IA)
Cryptographic module requirements and enhanced authentication mechanisms.
- IA-7: Cryptographic Module Authentication
- IA-5(2): PKI-Based Authentication
Media Protection (MP)
CUI-specific handling requirements for media storage, transport, and sanitization.
- MP-4: Media Storage
- MP-5: Media Transport
- MP-6(1): Review/Approve/Track Sanitization
System & Communications (SC)
Cryptographic protection, boundary defense, and information protection requirements.
- SC-13: FIPS 140-2 Cryptography
- SC-28: Protection at Rest
- SC-28(1): Cryptographic Protection at Rest
Map once. Apply everywhere.
The same security control often satisfies requirements across multiple frameworks. NIST 800-53 AC-2 maps to CMMC AC.L2-3.1.1, ISO 27001 A.9.2.1, and FedRAMP AC-2. When you've implemented a control once, Thalorin's Feynman Engine identifies all frameworks where that implementation provides coverage—maximizing the value of your compliance investments.
When reciprocity is denied
Reciprocity disputes happen. A receiving AO may refuse acceptance due to insufficient evidence, different risk interpretation, or enclave-specific concerns. DoD provides an escalation path: AO level → RMF TAG Chair → AO Council (DoD CISO). Thalorin documents the reciprocity request, denial rationale, and escalation history to support resolution.
Level 1: AO Negotiation
Direct discussion between originating and receiving AOs. Often resolves through additional evidence or clarification of implementation details.
Level 2: RMF TAG Chair
Technical Advisory Group chair mediates disputes. Reviews BoE quality and receiving AO concerns.
Level 3: AO Council (DoD CISO)
Final adjudication by DoD CISO-chaired council. Binding decision on reciprocity acceptance.
Thalorin tracks escalation status, generates required documentation, and maintains audit trail of all reciprocity decisions.
Reciprocity policy is strengthening
Recent policy updates push toward reciprocity as the default rather than exception. Organizations that invest in clean, well-documented authorizations now will benefit as these policies take effect.
Deputy SecDef Memo
Mandates reciprocity implementation "except when cybersecurity risk is proven too great." Shifts burden of proof to receiving organization to justify rejection.
OMB M-24-15
Establishes "presumption of adequacy" requiring civilian agencies to accept FedRAMP authorizations without additional validation. Creates FedRAMP Board replacing JAB.
DoD CC SRG Updates
Clarified IL5 as explicitly NSS-focused, positioning IL4 as appropriate for most CUI/mission data. Simplifies pathway selection for cloud workloads.
FedRAMP Roadmap
Pilots underway for reciprocity with external frameworks (SOC 2 Type 2, ISO 27001, HITRUST under consideration). OSCAL digital authorization packages in development.
Common questions
What does reciprocity actually entitle you to?
Acceptance of another authorizing official's assessment evidence, not automatic acceptance of their authorization decision. The receiving AO is still accepting risk in their own environment, which can differ in threat, mission and interconnection. So reciprocity removes the requirement to re-perform testing that has already been done to an equivalent standard; it does not remove the decision. Programmes that expect a transferable ATO experience this as reciprocity failing, when what failed was the expectation.
Why does FedRAMP authorization not simply carry into DoD?
Because the Department layers additional requirements on top of the FedRAMP baseline at the higher impact levels, and those additions are exactly the ones a commercial authorization would not have addressed — personnel requirements, location and jurisdiction constraints, connection and boundary requirements, and cryptographic expectations. The FedRAMP work is genuinely reusable underneath. What has to be produced is the delta, which is why knowing precisely which controls the delta contains is worth more than a general claim of equivalence.
What makes an assessment package actually reusable?
Traceability. A receiving AO can reuse a result if they can see what was tested, when, by whom, against which control and which system component, and what the result was. A package that presents conclusions without that chain forces re-testing, because the receiving official has no basis for accepting it. This is the practical reason to hold evidence bound to controls and assets rather than compiled per assessment — reusability is a property of how it was captured, not of what it is called.
How much of a package typically transfers?
It depends entirely on how far apart the two environments are, and any specific percentage offered without inspecting both packages is a guess. The reliable predictor is where the differences sit: common controls inherited from a shared platform transfer readily, system-specific technical controls transfer when the implementation is genuinely the same, and anything tied to the environment — physical, personnel, interconnection — generally does not. Establishing that split early is what makes the timeline predictable.
What is the most common reason a reciprocity request is refused?
The receiving official cannot establish that the two systems are the same system. A package that describes the system as authorized elsewhere, without showing how the instance in front of them differs in boundary, configuration, interconnection and inherited controls, gives them nothing to accept. Refusals are far more often a documentation gap of this kind than a disagreement about security posture.
Regulatory state described as of August 2026. Requirements change; verify against the current rule before relying on any date above.
Stop re-authorizing what's already authorized
See how Thalorin can help you leverage existing authorizations across agency boundaries with automated gap analysis and reciprocity package generation.