CISA BOD 25-01 Compliance: What U.S. Government Agencies Need to Know
U.S. government agencies are required to bring their Microsoft 365 cloud services into compliance with a recent Binding Operational Directive. Here’s how Tenable can help.
Overview
Malicious threat actors are constantly targeting cloud environments. The risk of compromise can be reduced by enforcing secure configurations of security controls. With this goal in mind, the Cybersecurity and Infrastructure Security Agency (CISA) created the Secure Cloud Business Applications (SCuBA) project. The SCuBA project currently provides secure configuration baselines for Microsoft 365 and Google Workspace.
In December 2024, as part of the SCuBA project, CISA released a Binding Operational Directive (BOD) 25-01: Implementation Guidance for Implementing Secure Practices for Cloud Services. This directive requires U.S. government agencies and departments in the federal civilian executive branch to implement secure configuration baselines for certain software as a service (SaaS) products.
Scope
The scope of the BOD 25-01 includes all production or operational cloud tenants (operating in or as a federal information system) utilizing Microsoft 365. CISA may release additional SCuBA Secure Configuration Baselines for other cloud products which would fall under the scope of this directive. The complete list of required configurations is available here.
While the CISA BOD 25-01 applies to government agencies, any organization using Microsoft 365 would reduce the risk of compromise by adhering to these baselines.
Required actions
According to BOD 25-01, there are several required actions for in-scope cloud tenant agencies that shall be completed by the following dates:
- February 21, 2025 - following CISA reporting instructions:
- submit tenant name and system owning agency/component for each tenant
- submit an updated the inventory annually in the first quarter
- April 25, 2025 - deploy SCuBA assessment tools and begin continuous reporting
- June 20, 2025 - implement all mandatory SCuBA policies identified at BOD 25-01 Required Configurations.
In-scope cloud tenants are also required to:
- Implement all future updates to mandatory SCuBA policies
- Implement all mandatory SCuBA Secure Configuration Baselines and begin continuous monitoring prior to granting an Authorization to Operate for new cloud tenants.
Required configurations
As of March 2025, the following configurations are required for BOD 25-01:
Microsoft 365 (M365)
Microsoft Entra ID
| MS.AAD.1.1v1 | Legacy authentication SHALL be blocked. |
| MS.AAD.2.1v1 | Users detected as high risk SHALL be blocked. |
| MS.AAD.2.3v1 | Sign-ins detected as high risk SHALL be blocked. |
| MS.AAD.3.1v1 | Phishing-resistant MFA SHALL be enforced for all users. |
| MS.AAD.3.2v1 | If Phishing-resistant MFA has not been enforced yet, then an alternative MFA method SHALL be enforced for all users. |
| MS.AAD.3.3v1 | If Phishing-resistant MFA has not been enforced yet and Microsoft Authenticator is enabled, it SHALL be configured to show login context information. |
| MS.AAD.3.4v1 | The Authentication Methods Manage Migration feature SHALL be set to Migration Complete. |
| MS.AAD.3.6v1 | Phishing-resistant MFA SHALL be required for Highly Privileged Roles. |
| MS.AAD.5.1v1 | Only administrators SHALL be allowed to register applications. |
| MS.AAD.5.2v1 | Only administrators SHALL be allowed to consent to applications. |
| MS.AAD.5.3v1 | An admin consent workflow SHALL be configured for applications. |
| MS.AAD.5.4v1 | Group owners SHALL NOT be allowed to consent to applications. |
| MS.AAD.6.1v1 | User passwords SHALL NOT expire. |
| MS.AAD.7.1v1 | A minimum of two users and a maximum of eight users SHALL be provisioned with the Global Administrator role. |
| MS.AAD.7.2v1 | Privileged users SHALL be provisioned with finer-grained roles instead [of] Global Administrator. |
| MS.AAD.7.3v1 | Privileged users SHALL be provisioned cloud-only accounts that are separate from an on-premises directory or other federated identity providers. |
| MS.AAD.7.4v1 | Permanent active role assignments SHALL NOT be allowed for highly privileged roles except for emergency and service accounts. |
| MS.AAD.7.5v1 | Provisioning users to highly privileged roles SHALL NOT occur outside of a PAM system, because this bypasses critical controls the PAM system provides. |
| MS.AAD.7.6v1 | Activation of the Global Administrator role SHALL require approval. |
| MS.AAD.7.7v1 | Eligible and Active highly privileged role assignments SHALL trigger an alert. |
| MS.AAD.7.8v1 | User activation of the Global Administrator role SHALL trigger an alert. |
Microsoft Defender
| MS.DEFENDER.1.1v1 | The standard and strict preset security policies SHALL be enabled. |
| MS.DEFENDER.1.2v1 | All users SHALL be added to Exchange Online Protection in either the standard or strict preset security policy. |
| MS.DEFENDER.1.3v1 | All users SHALL be added to Defender for Office 365 Protection in either the standard or strict preset security policy. |
| MS.DEFENDER.1.4v1 | Sensitive accounts SHALL be added to Exchange Online Protection in the strict preset security policy. |
| MS.DEFENDER.1.5v1 | Sensitive accounts SHALL be added to Defender for Office 365 Protection in the strict preset security policy. |
| MS.DEFENDER.4.1v2 | A custom policy SHALL be configured to protect PII and sensitive information, as defined by the agency, blocking at a minimum: credit card numbers, U.S. Individual Taxpayer Identification Numbers (ITINs), and U.S. Social Security numbers (SSNs). |
| MS.DEFENDER.5.1v1 | At a minimum, the alerts required by the CISA M365 Secure Configuration Baseline for Exchange Online SHALL be enabled. |
| MS.DEFENDER.6.1v1 | Microsoft Purview Audit (Standard) logging SHALL be enabled. |
| MS.DEFENDER.6.2v1 | Microsoft Purview Audit (Premium) logging SHALL be enabled for ALL users. |
Exchange Online
| MS.EXO.1.1v1 | Automatic forwarding to external domains SHALL be disabled. |
| MS.EXO.2.2v2 | An SPF policy SHALL be published for each domain that fails all non-approved senders. |
| MS.EXO.4.1v1 | A DMARC policy SHALL be published for every second-level domain. |
| MS.EXO.4.2v1 | The DMARC message rejection option SHALL be p=reject. |
| MS.EXO.4.3v1 | The DMARC point of contact for aggregate reports SHALL include [email protected]. |
| MS.EXO.5.1v1 | SMTP AUTH SHALL be disabled. |
| MS.EXO.6.1v1 | Contact folders SHALL NOT be shared with all domains. |
| MS.EXO.6.2v1 | Calendar details SHALL NOT be shared with all domains. |
| MS.EXO.7.1v1 | External sender warnings SHALL be implemented. |
| MS.EXO.13.1v1 | Mailbox auditing SHALL be enabled. |
Power Platform
| MS.POWERPLATFORM.1.1v1 | The ability to create production and sandbox environments SHALL be restricted to admins. |
| MS.POWERPLATFORM.1.2v1 | The ability to create trial environments SHALL be restricted to admins. |
| MS.POWERPLATFORM.2.1v1 | A DLP policy SHALL be created to restrict connector access in the default Power Platform environment. |
| MS.POWERPLATFORM.3.1v1 | Power Platform tenant isolation SHALL be enabled. |
SharePoint Online and OneDrive
| MS.SHAREPOINT.1.1v1 | External sharing for SharePoint SHALL be limited to Existing Guests or Only People in your Organization. |
| MS.SHAREPOINT.1.2v1 | External sharing for OneDrive SHALL be limited to Existing Guests or Only People in your Organization. |
| MS.SHAREPOINT.2.1v1 | File and folder default sharing scope SHALL be set to Specific People (only the people the user specifies). |
| MS.SHAREPOINT.2.2v1 | File and folder default sharing permissions SHALL be set to View only. |
Microsoft Teams
| MS.TEAMS.1.2v1 | Anonymous users SHALL NOT be enabled to start meetings. |
| MS.TEAMS.2.1v1 | External access for users SHALL only be enabled on a per-domain basis. |
| MS.TEAMS.2.2v1 | Unmanaged users SHALL NOT be enabled to initiate contact with internal users. |
| MS.TEAMS.3.1v1 | Contact with Skype users SHALL be blocked. |
| MS.TEAMS.4.1v1 | Teams email integration SHALL be disabled. |
Additional configurations
In addition to the required configurations, the following configurations can also be evaluated:
Microsoft 365 (M365)
Microsoft Entra ID
| MS.AAD.2.2v1 | A notification SHOULD be sent to the administrator when high-risk users are detected. |
| MS.AAD.3.7v1 | Managed devices SHOULD be required for authentication. |
| MS.AAD.3.8v1 | Managed Devices SHOULD be required to register MFA. |
| MS.AAD.7.9v1 | User activation of other highly privileged roles SHOULD trigger an alert. |
| MS.AAD.8.1v1 | Guest users SHOULD have limited or restricted access to Microsoft Entra ID directory objects. |
| MS.AAD.8.2v1 | Only users with the Guest Inviter role SHOULD be able to invite guest users. |
Microsoft Defender
| MS.DEFENDER.2.1v1 | User impersonation protection SHOULD be enabled for sensitive accounts in both the standard and strict preset policies. |
| MS.DEFENDER.2.2v1 | Domain impersonation protection SHOULD be enabled for domains owned by the agency in both the standard and strict preset policies. |
| MS.DEFENDER.2.3v1 | Domain impersonation protection SHOULD be added for important partners in both the standard and strict preset policies. |
| MS.DEFENDER.3.1v1 | Safe attachments SHOULD be enabled for SharePoint, OneDrive, and Microsoft Teams. |
| MS.DEFENDER.4.2v1 | The custom policy SHOULD be applied to Exchange, OneDrive, SharePoint, Teams chat, and Devices. |
| MS.DEFENDER.4.3v1 | The action for the custom policy SHOULD be set to block sharing sensitive information with everyone. |
| MS.DEFENDER.4.4v1 | Notifications to inform users and help educate them on the proper use of sensitive information SHOULD be enabled in the custom policy. |
Exchange Online
| MS.EXO.3.1v1 | DKIM SHOULD be enabled for all domains. |
| MS.EXO.4.4v1 | An agency point of contact SHOULD be included for aggregate and failure reports. |
| MS.EXO.12.1v1 | IP allow lists SHOULD NOT be created. |
| MS.EXO.12.2v1 | Safe lists SHOULD NOT be enabled. |
Power Platform
| MS.POWERPLATFORM.2.2v1 | Non-default environments SHOULD have at least one DLP policy affecting them. |
| MS.POWERPLATFORM.5.1v1 | The ability to create Power Pages sites SHOULD be restricted to admins. |
SharePoint Online and OneDrive
| MS.SHAREPOINT.1.3v1 | External sharing SHALL be restricted to approved external domains and/or users in approved security groups per interagency collaboration needs. |
| MS.SHAREPOINT.3.1v1 | Expiration days for Anyone links SHALL be set to 30 days or less. |
| MS.SHAREPOINT.3.2v1 | The allowable file and folder permissions for links SHALL be set to View only. |
| MS.SHAREPOINT.3.3v1 | Reauthentication days for people who use a verification code SHALL be set to 30 days or less. |
Microsoft Teams
| MS.TEAMS.1.1v1 | External meeting participants SHOULD NOT be enabled to request control of shared desktops or windows. |
| MS.TEAMS.1.3v1 | Anonymous users and dial-in callers SHOULD NOT be admitted automatically. |
| MS.TEAMS.1.4v1 | Internal users SHOULD be admitted automatically. |
| MS.TEAMS.1.5v1 | Dial-in users SHOULD NOT be enabled to bypass the lobby. |
| MS.TEAMS.1.6v1 | Meeting recording SHOULD be disabled. |
| MS.TEAMS.1.7v1 | Record an event SHOULD be set to Organizer can record. |
| MS.TEAMS.2.3v1 | Internal users SHOULD NOT be enabled to initiate contact with unmanaged users. |
| MS.TEAMS.5.1v1 | Agencies SHOULD only allow installation of Microsoft apps approved by the agency. |
| MS.TEAMS.5.2v1 | Agencies SHOULD only allow installation of third-party apps approved by the agency. |
| MS.TEAMS.5.3v1 | Agencies SHOULD only allow installation of custom apps approved by the agency. |
How Tenable can help
Tenable Vulnerability Management and Nessus customers can audit the posture of their Microsoft 365 environment with the CISA SCuBA for Microsoft 365 audit files:
- CISA SCuBA Microsoft 365 Entra ID
- CISA SCuBA Microsoft 365 Defender
- CISA SCuBA Microsoft 365 Exchange Online
- CISA SCuBA Microsoft 365 Power Platform
- CISA SCuBA Microsoft 365 SharePoint Online OneDrive
- CISA SCuBA Microsoft 365 Teams
More details for configuring your SCuBA Microsoft 365 environment for Compliance Auditing are available at Configure Azure for a Compliance Audit.
Mark Beblow
Staff Research Engineer, Audits and Compliance
Mark Beblow is Staff Research Engineer, Audits and Compliance at Tenable. He joined the company in 2015 with over 10 years experience in information security roles within the mining industry. He is specialized in cloud security and leveraging AI to solve problems in the information security and compliance domains.
Related articles
Cybersecurity Snapshot: Verizon DBIR Finds Attackers Feast on Vulnerability Exploits for Initial Access, While MITRE ATT&CK Adds Mobile, Cloud, ESXi Threat Intel
Check out highlights from this year’s Verizon DBIR, including a surge in zero-day exploits targeting edge devices and VPNs. Plus, find out what’s new in the latest version of MITRE ATT&CK. Also, see what Tenable webinar attendees said about AI security. And get the latest on ransomware preparedness ...
Cybersecurity Snapshot: NIST Aligns Its Privacy and Cyber Frameworks, While Researchers Warn About Hallucination Risks from GenAI Code Generators
Check out NIST’s effort to further mesh its privacy and cyber frameworks. Plus, learn why code-writing GenAI tools can put developers at risk of package-confusion attacks. Also, find out what Tenable webinar attendees said about identity security. And get the latest on the MITRE CVE program and on a...
Geopolitics Just Cranked Up Your Threat Model, Again. Here’s What Cyber Pros Need to Know
If it feels like your entire cybersecurity program is once again operating on a geopolitical fault line, you're not imagining things....
- Risk-based Vulnerability Management
- Vulnerability Management
- Government