Under active development Content is continuously updated and improved

KSI-AFR-FSIFedRAMP Security Inbox

LOW
MODERATE

Formerly KSI-AFR-08

>Control Description

Operate a secure inbox to receive critical communication from FedRAMP and other government entities in alignment with FedRAMP Security Inbox (FSI) requirements and persistently address all related requirements and recommendations.
Defined terms:
FedRAMP Security Inbox
Persistently

>FRMR Requirements
19

Normative requirements from the FedRAMP Requirements and Recommendations document — 14 mandatory, 3 recommended, 2 optional.

Mandatory14
MUST

Verified Emails

FedRAMP MUST send messages to cloud service providers using an official @fedramp.gov or @gsa.gov email address with properly configured Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication Reporting and Conformance (DMARC) email authentication.

FSI-FRP-VRE
FedRAMP
MUST

Criticality Designators

FedRAMP MUST convey the criticality of the message in the subject line, IF the message requires an elevated reaction, using one of the following designators:

FSI-FRP-CDS
FedRAMP
  • **Emergency:** There is a potential incident or crisis such that FedRAMP requires an extremely urgent reaction; emergency messages will contain aggressive timeframes for reaction and failure to meet these timeframes will result in corrective action.
  • **Emergency Test:** FedRAMP requires an extremely urgent reaction to confirm the functionality and effectiveness of the FedRAMP Security Inbox; emergency test messages will contain aggressive timeframes for reaction and failure to meet these timeframes will result in corrective action.
  • **Important:** There is an important issue that FedRAMP requires the cloud service provider to address; important messages will contain reasonable timeframes for reaction and failure to meet these timeframes may result in corrective action.
MUST

Use FedRAMP_Security Email in Emergencies

FedRAMP MUST send Emergency and Emergency Test designated messages from fedramp_security@gsa.gov OR fedramp_security@fedramp.gov.

FSI-FRP-UFS
FedRAMP
MUST

Public Notice of Emergency Tests

FedRAMP MUST post a public notice at least 10 business days in advance of sending an Emergency Test message; such notices MUST include explanation of the likely expected actions and timeframes for the Emergency Test message.

FSI-FRP-PNT
FedRAMP

Public notice may include blog posts, social media posts, announcements during Community Updates, or e-blasts.

As this process matures, additional confirmed options may become available.

MUST

Required Actions

FedRAMP MUST clearly specify the required actions in the body of messages that require an elevated reaction.

FSI-FRP-RQA
FedRAMP
MUST

Elevated Reaction Timeframes

FedRAMP MUST clearly specify the expected timeframe for completing required actions in the body of messages that require an elevated reaction; timeframes for actions will vary depending on the situation but the default timeframes to provide an estimated resolution time for Emergency and Emergency Test designated messages will be as follows:

FSI-FRP-ERT
FedRAMP
  • **High Impact:** within 12 hours
  • **Moderate Impact:** by 3:00 p.m. Eastern Time on the 2nd business day
  • **Low Impact:** by 3:00 p.m. Eastern Time on the 3rd business day
MUST

Explain Corrective Actions

FedRAMP MUST clearly specify the corrective actions that will result from failure to complete the required actions in the body of messages that require an elevated reaction; such actions may vary from negative ratings in the FedRAMP Marketplace to suspension of FedRAMP authorization depending on the severity of the event.

FSI-FRP-COR
FedRAMP
MUST

Maintain a FedRAMP Security Inbox

Providers MUST establish and maintain an email address to receive messages from FedRAMP; this inbox is a FedRAMP Security Inbox (FSI).

FSI-CSO-INB
Providers

Unless otherwise notified, FedRAMP will use the listed Security Email on the Marketplace for these notifications.

If a provider establishes a new inbox in reaction to this guidance that is different from the Security EMail then they must follow the requirements in FSI-CSO-NOC to notify FedRAMP.

MUST

Notification of Changes

Providers MUST immediately notify FedRAMP of any changes in addressing for their FedRAMP Security Inbox by emailing info@fedramp.gov with the name and FedRAMP ID of the cloud service offering and the updated email address.

FSI-CSO-NOC
Providers
MUST

Trust @fedramp.gov and @gsa.gov

Providers MUST treat any email originating from an @fedramp.gov or @gsa.gov email address as if it was sent from FedRAMP by default; if such a message is confirmed to originate from someone other than FedRAMP then FedRAMP Security Inbox requirements no longer apply.

FSI-CSO-TFG
Providers
MUST

Receive Email Without Disruption

Providers MUST receive and react to email messages from FedRAMP without disruption and without requiring additional actions from FedRAMP.

FSI-CSO-RCV
Providers
MUST

Complete Required Actions

Providers MUST complete the required actions in Emergency or Emergency Test designated messages sent by FedRAMP within the timeframe included in the message.

FSI-CSO-CRA
Providers
MUST

Emergency Message Routing

Providers MUST route Emergency designated messages sent by FedRAMP to a senior security official for their awareness.

FSI-CSO-EMR
Providers
MUST

Implementation Summaries

Providers MUST maintain simple high-level summaries of at least the following for each Key Security Indicator:

KSI-CSX-SUM
Providers
  • Goals for how it will be implemented and validated, including clear pass/fail criteria and traceability
  • The consolidated _information resources_ that will be validated (this should include consolidated summaries such as "all employees with privileged access that are members of the Admin group")
  • The machine-based processes for _validation_ and the _persistent_ cycle on which they will be performed (or an explanation of why this doesn't apply)
  • The non-machine-based processes for _validation_ and the _persistent_ cycle on which they will be performed (or an explanation of why this doesn't apply)
  • Current implementation status
  • Any clarifications or responses to the assessment summary
Recommended3
SHOULD

Important Message Actions

Providers SHOULD complete the required actions in Important designated messages sent by FedRAMP within the timeframe specified in the message.

FSI-CSO-IMA
Providers
SHOULD

Acknowledge Receipt

Providers SHOULD promptly and automatically acknowledge the receipt of messages received from FedRAMP in their FedRAMP Security Inbox.

FSI-CSO-ACK
Providers
SHOULD

Application within MAS

Providers SHOULD apply ALL Key Security Indicators to ALL aspects of their cloud service offering that are within the FedRAMP Minimum Assessment Scope.

KSI-CSX-MAS
Providers
2 optional guidance (MAY)
Optional Guidance2
MAY

Reaction Metrics

FedRAMP MAY track and publicly share the time required by cloud service providers to take the actions specified in messages that require an elevated reaction.

FSI-FRP-RPM
FedRAMP
MAY

AFR Order of Criticality

Providers MAY use the following order of criticality for approaching Authorization by FedRAMP Key Security Indicators for an initial authorization package:

KSI-CSX-ORD
Providers
  • Minimum Assessment Scope (MAS)
  • Authorization Data Sharing (ADS)
  • Using Cryptographic Modules (UCM)
  • Vulnerability Detection and Response (VDR)
  • Significant Change Notifications (SCN)
  • Persistent Validation and Assessment (PVA)
  • Secure Configuration Guide (RSC)
  • Collaborative Continuous Monitoring (CCM)
  • FedRAMP Security Inbox (FSI)
  • Incident Communications Procedures (ICP)

>Trust Center Components
3

Ways to express your implementation of this indicator — approaches vary by organization size, complexity, and data sensitivity.

From the field: Mature implementations make security contact information machine-discoverable — RFC 9116-compliant security.txt at a well-known URI, PSIRT inbox with published SLA metrics and automated acknowledgment, and DNS-based security contact records. The security inbox becomes a measurable service with response time tracking, not a compliance checkbox.

Security.txt File

Product Security Features

RFC 9116-compliant security.txt at /.well-known/security.txt — machine-discoverable disclosure and contact information

Automated: Fetch /.well-known/security.txt and validate RFC 9116 compliance

Security Contact Information

Documents & Reports

Published security inbox, PSIRT contact details, and responsible disclosure channels with response time metrics

Incident Reporting SLA

Policies

Human-readable SLAs for security inbox response times and escalation procedures

>Programmatic Queries

Beta
Security

CLI Commands

Check for security.txt file
curl -s https://example.com/.well-known/security.txt
Verify security.txt has required fields
curl -s https://example.com/.well-known/security.txt | grep -E "^(Contact|Expires|Encryption|Policy):"

>20x Assessment Focus Areas

Aligned with FedRAMP 20x Phase Two assessment methodology

Completeness & Coverage:

  • Does the FedRAMP Security Inbox cover all communication types FedRAMP or government entities may send (vulnerability alerts, incident directives, policy updates)?
  • Are all personnel who need to act on security inbox communications identified, and is there coverage for absences and role changes?
  • How do you ensure after-hours, weekend, and holiday communications are not missed or delayed?
  • What happens when a communication requires action from a team not currently monitoring the inbox — how is routing guaranteed?

Automation & Validation:

  • What automated alerting fires when a new message arrives in the security inbox, and what happens if that alerting mechanism fails?
  • How do you automatically verify the authenticity of communications claiming to originate from FedRAMP or government entities (e.g., DKIM, S/MIME)?
  • What automated SLA tracking ensures response timeframes are met, and what escalation triggers if a message goes unacknowledged?
  • How do you test that the inbox and its monitoring integrations are functioning — do you run synthetic test messages?

Inventory & Integration:

  • How does the security inbox integrate with your incident management, ticketing, or SOAR platform to ensure communications become trackable action items?
  • Is the inbox connected to an on-call rotation tool (PagerDuty, Opsgenie), and how do you keep the rotation roster current?
  • What other communication channels (Slack, Teams, phone) are linked to inbox alerts, and how do you prevent alert fatigue from duplicating across channels?

Continuous Evidence & Schedules:

  • How do you demonstrate the inbox has been actively monitored and responded to over the past 90 days?
  • Is inbox activity and response-time data available via API or dashboard, or only through manual log review?
  • What evidence shows that every FedRAMP communication received was acknowledged and actioned within defined SLAs?
  • How do you detect if inbox monitoring degrades — for example, if the alerting integration silently disconnects?

Update History

2026-02-04Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

Ask AI

Configure your API key to use AI features.