NSF1 maps to CIS 6.5: both are targeted at protecting administrative accounts with multi-factor authentication. However, NSF1 includes one complication: it specifies the use of “phishing resistant MFA.” The term “phishing resistant MFA” is not defined by the NSF Critical Controls, nor is it defined in NIST SP 800-53, NIST SP 800-171, or the CIS Controls. A similar term, “Phishing Resistance,” was recently defined in a separate publication, NIST SP 800-64-4, as “[t]he ability of the authentication protocol to prevent the disclosure of authentication secrets and valid authenticator outputs to an impostor verifier without reliance on the vigilance of the claimant.” NIST SP 800-64-4 does not provide examples of what might constitute “phishing resistant MFA.”

Numerous other sources have provided their perspective on what constitutes “phishing resistant MFA” (see, e.g., CISA, Salesforce). Many of these sources recommend specific implementations (e.g., FIDO2/ WebAuthn; passkeys), although there is no universally accepted definition or standard. While these sources provide useful context and guidance, we do not believe they are authoritative for the purposes of interpreting the NSF Critical Controls.

Given this lack of a commonly understood meaning, we interpret “phishing resistant MFA” as recommending organizations prioritize relatively more secure implementations of MFA (e.g., “verified pushes”) and to avoid less secure implementations (e.g., SMS pushes; phone calls). While hardware tokens are very likely to qualify as “phishing resistant MFA,” we do not believe they are strictly required. Importantly, “phishing resistant” does not mean “phishing proof,” so organizations have the flexibility to select the MFA implementations that make the most sense for their mission and needs.

Regarding supporting practices, CIS 5.1 will support implementation of NSF1 by making sure an organization has an inventory of its administrative accounts. Maintaining an inventory of administrative accounts will ease the process of rolling out phishing resistant MFA and other protections for those accounts. Similarly, Must 8 requires that the organization's cybersecurity program extends to all entities with access to or authority over information assets, which might include third parties (e.g., contractors; external researchers) who may require administrative access.

NSF2 maps to CIS 6.4: both are targeted at protecting remote network access with multi-factor authentication. However, like NSF1, NSF2 includes one complication: it specifies the use of “phishing resistant MFA.” For our discussion of the phrase “phishing resistant MFA” and our recommended interpretation, see NSF1 Commentary. Additionally, it is important to note that an organization's decision regarding phishing resistant MFA for NSF1 (administrator accounts) and NSF2 (remote access) may differ. Remote network access often imposes more constraints on the types of MFA that may be feasible, particularly for research organizations that may have large numbers of remote collaborators from different institutions.

Regarding supporting practices, CIS 12.7 provides a structured approach to provide remote network access via a Virtual Private Network (VPN), which can be easily enhanced to include MFA. Similarly, Must 8 requires that the organization's cybersecurity program extends to all entities with access to or authority over information assets, which might include third parties (e.g., contractors; external researchers) who may require remote network access.

NSF3 maps to CIS 5.4: this Safeguard requires restricting “administrator privileges to dedicated administrator accounts on enterprise assets. Conduct general computing activities, such as internet browsing, email, and productivity suite use, from the user's primary, non-privileged account.” NSF introduces the term “limited scope” in the title of this control. This term is not defined by the NSF Critical Controls, nor is it defined in NIST SP 800-53, NIST SP 800-171, or the CIS Controls in the context of restricting administrative accounts.

We interpret the phrase “limited scope” not as a specific requirement but rather as a guiding principle when defining the scope of administrative accounts. (This is similar to the principles of “Least Privilege” and “Separation of Duties.”) Although creating separate administrator accounts for different administrative functions reduces the risk from the compromise of any individual account, there is no limiting principle or clear test for when “enough is enough.” We believe, therefore, that organizations have the flexibility to define what “limited scope” means for their organization's privileged/administrative accounts. However, in all cases, organizations should ensure that administrative privileges are limited to dedicated administrator accounts, in line with CIS 5.4.

Regarding supporting practices, CIS 6.8 describes how organizations can implement “role-based access control,” which defines with greater particularity what organizational roles are and what accesses they require. This will help organizations define and document what their different administrator roles should be, and more consistently limit those roles to only the individuals who need those levels of access.

NSF4 maps to CIS 10.1 and CIS 10.2. Each of these relates to deploying anti-malware software.

CIS 10.1 says “deploy and maintain anti-malware software on all enterprise assets.” We draw no particular distinction between NSF4's reference to deploying anti-malware to “systems capable” and the CIS reference to deploying anti-malware to “all enterprise assets.”

CIS 10.2 says “configure automatic updates for anti-malware signature files on all enterprise assets.” Trusted CI considers this a full mapping, as configuring automatic anti-malware signature updates is crucial to effectively “maintain” anti-malware software.

Regarding supporting practices, CIS 1.1 and CIS 2.1 provide a structured approach for determining and recording which assets are capable of running anti-malware software and documenting exceptions for when assets aren't capable of running such software.

Note: While NSF4 focuses on the deployment and maintenance of anti-malware for systems capable of running such software, NSF5 specifies that the anti-malware software being used should have EDR functionality. In most cases, NSF4 is inherently addressed through the implementation of NSF5.

NSF5 maps to CIS 10.7. When deploying and maintaining anti-malware software (NSF4), NSF5 specifies that the software being used should have Endpoint Detection and Response (EDR) functionality, which includes most modern anti-malware software.

“EDR” is a broad commercial term and can vary in definition. Trusted CI interprets EDR functionality broadly to include any tool capable of detecting and investigating endpoint behavior, which goes a step beyond traditional, signature-based anti-malware. Additional examples of solutions that meet this inclusive definition of EDR include “behavior-based” or “non-signature based” mechanisms. NIST SP 800-53 provides various examples of these mechanisms, including: 1) artificial intelligence techniques that use heuristics to detect, analyze, and describe the characteristics or behavior of malicious code; 2) the provision of controls against such code for which signatures do not yet exist or for which existing signatures may not be effective; and 3) reputation-based technologies.

Regarding supporting practices, enabling anti-exploitation features on assets and software (CIS 10.5) and centrally managing anti-malware software (CIS 10.6) can help improve the overall implementation of this NSF control. Deploying a host-based intrusion prevention solution (CIS 13.7) may also constitute EDR functionality for the purposes of NSF5.

NSF6 maps to CIS 11.1 and CIS 11.4: each of these relate to the creation and protection of system backups.

CIS 11.1 establishes the basic requirements for a data recovery process, including defining the scope of the organization's data recovery activities, explicitly prioritizing system backups, and describing steps taken to secure the backups.

CIS 11.4 directs the use of physical and/or logical isolation of the backup data. Physical and/or logical isolation of the backup data is one of the most effective practices to prevent unauthorized changes to or deletions of backup data.

The term “immutable” generally refers to something that cannot be changed or deleted. In real-world deployments of backup systems, truly “immutable” backup data is impossible. Instead, we recommend viewing the term “immutable” not as a specific requirement, but as a guiding principle when selecting controls to prevent the unauthorized change or deletion of backup data. Common examples include encrypting backups with strict key management, disallowing changes to existing backups, and keeping backups physically and logically isolated from the system they are backing up (CIS 11.4).

In terms of supporting practices, CIS 11.2 is focused on automating backups to ensure they are consistently maintained and up-to-date. CIS 11.3 highlights that backup data should have at least the same level of protection as the system it is backing up. This serves as a good guiding principle when determining protections for backup data.

NSF7 maps to CIS 11.1 and CIS 11.4. Similar to NSF6, these both relate to the creation and protection of backups. However, NSF6 is focused on backups of systems, whereas NSF7 is focused on backups of critical research data. For our discussion of CIS 11.1 and CIS 11.4, as well as our recommended interpretation of the word “immutable,” see NSF6 Commentary.

The phrase “critical research data” is not defined in NSF7, nor does it have a consistent definition across the federal government. Notably, the modifier “critical” makes this term narrower than the term “research data,” which is defined in 2 CFR 200.315 as “the recorded factual material commonly accepted in the scientific community as necessary to validate research findings.” Given this lack of a commonly accepted definition, it is Trusted CI's view that the determination of what constitutes “critical research data” is a decision made by the leadership of the research project, in consultation with relevant stakeholders.

In terms of supporting practices, CIS 11.2 is focused on automating backups to ensure they are consistently maintained and up-to-date. CIS 11.3 highlights that backup data should have at least the same level of protection as the system it is backing up. This serves as a good guiding principle when determining protections for backup data.

NSF8 maps to CIS 11.5: both describe testing the organization's data recovery / backup processes. Notably, CIS 11.5 requires that backups be tested quarterly, whereas NSF8 only requires that the testing occur annually. Additionally, NSF8 specifies testing both the integrity of the backup data and restoration of the backups at a large scale. Although not specified in CIS 11.5, we do not view this language as substantively expanding upon what is required by CIS 11.5, but rather providing greater clarity on how to effectively test an organization's backups.

Note: NSF6 and/or NSF7 are prerequisites to NSF8 as backup processes must first be in place to test them.

NSF9 maps to a number of CIS Safeguards in the “Audit Log Management” family of controls.

CIS 8.1 instructs organizations to “Establish and Maintain an Audit Log Management Process.” This lays out the minimum requirements for an audit log management process, including definitions of what logs to collect, the level of detail, the retention period, and review procedures for collected logs. It is also advisable to include in this process any gaps in coverage, or any special considerations for systems that can't adhere to the defined process.

CIS 8.2 instructs organizations to enable log collection across “enterprise assets.” We draw no particular distinction between the phrase “enterprise assets” as used by CIS 8.2 and the term cyberinfrastructure (CI) used by NSF9.

CIS 8.9 instructs organizations to centrally collect and store audit logs. CIS 8.9 also suggests “leveraging a SIEM tool” to aid in this centralization and retention process. While using a SIEM isn't required, it can be extremely useful for managing large amounts of log events or disparate types of logs.

CIS 8.11 also instructs organizations to review audit logs to “detect anomalies or abnormal events” and specifies that organizations conduct “reviews on a weekly, or more frequent basis.” Importantly, NSF9 does not specify a frequency with which organizations must review their audit logs. We therefore interpret NSF9 to grant organizations the discretion to select a frequency of audit log reviews that makes sense for them.

Regarding supporting practices, all of the remaining Safeguards in the CIS 8 control family should be considered when developing and implementing NSF9. Notably, CIS presents Safeguards within a control family sequentially and in order of prioritization: Organizations using CIS 8 to guide their audit log management process are advised to work through the Safeguards roughly in the order presented by CIS.

NSF10 maps to CIS 12.2: Both emphasize the importance of establishing a secure network architecture using network segmentation.

CIS 12.2 provides additional details not included in NSF10, including having the network architecture address “least privilege and availability,” which, while not required, should also be considered when establishing a secure network architecture. CIS 12.2 also includes guidance on what implementation might look like, including “documentation, policy, and design components.” These are not hard requirements, but should be reviewed and considered.

Regarding supporting practices, the CIS Safeguards listed here address the second sentence of the NSF Control “[t]his may include any method of segmentation…” These Safeguards should be considered as guidance or examples of methods to consider when implementing network segmentation. Notably, not all of these Safeguards may be applicable to the network(s) in question, so it is recommended to evaluate each one to determine if it is appropriate to the network(s) being segmented.

NSF11 maps to CIS 1.1 and CIS 2.1. Each of these relate to the establishment of hardware and software asset inventories.

CIS 1.1 instructs organizations to “Establish and maintain an accurate, detailed, and up-to-date inventory of all enterprise assets with the potential to store or process data, to include: end-user devices…”

CIS 2.1 similarly covers software inventories, instructing organizations to “Establish and maintain a detailed inventory of all licensed software installed on enterprise assets… and review and update the software inventory bi-annually, or more frequently.”

NSF11's use of the term “critical infrastructure,” defined here as “systems and devices that maintain and provide access to services,” is distinct from definitions found in other federal sources (e.g., NIST 800-53r5, RA-2, PM-5, CISA). Notably, CIS 1.1 has an even broader scope, applying to “all enterprise assets with the potential to store or process data.” Organizations should define for themselves what constitutes “critical infrastructure” for the purposes of NSF11 and prioritize inventorying those assets. Once all assets the organization considers critical infrastructure are inventoried, we recommend the organization moves on to inventory the broader category of assets highlighted in CIS 1.1.

Regarding Supporting Practices, Must 3 (Information Assets) provides additional information and recommendations regarding inventory collection. The remaining Safeguards in CIS Controls 1 and 2 offer additional methods for gathering and maintaining hardware and software inventories, reducing coverage gaps and supporting automatic collection of detailed asset information. CIS presents Safeguards within a control family sequentially and in order of prioritization: Organizations using CIS Controls 1 & 2 to guide their inventories are advised to work through the Safeguards roughly in the order presented by CIS. Finally, CIS 12.4 (network documentation) complements these by providing relational context between computing, information, and network assets.

NSF12 maps to CIS 7.1, CIS 7.2, and part of CIS 7.7. Each of these relates to vulnerability management.

CIS 7.1 instructs organizations to “Establish and maintain a documented vulnerability management process for enterprise assets. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard.”

CIS 7.2 covers the accompanying remediation strategy, “Establish and maintain a risk-based remediation strategy documented in a remediation process, with monthly, or more frequent, reviews.”

NSF12 also maps partially to CIS 7.7 which requires organizations to “Remediate detected vulnerabilities in software through processes and tooling on a monthly, or more frequent, basis, based on the remediation process.” While NSF12 does not specify a frequency for organizations to remediate vulnerabilities, we encourage organizations to identify a frequency that makes sense for their mission and document that decision in their vulnerability management process.

The CIS controls mapped here separate process implementation and documentation (7.1), remediation strategy development and documentation (7.2), and remediation execution (7.7). NSF12 treats these as integrated components of a single “program” or “framework” for addressing “systems and software through the cyberinfrastructure.” Organizations should consider this scope in context of the requirements in NSF 11: any system or device captured in inventory is in-scope for vulnerability management, and the program should address all information assets (hardware, software, and data IT and OT systems) on a regular basis according to its threat model.

Regarding supporting practices, the remaining CIS 7 Safeguards bring additional efficiency to the process in CIS 7.1 through automation: CIS 7.3 and CIS 7.4 cover automated OS and application patching, while CIS 7.5 and CIS 7.6 address automated vulnerability scanning in internal and external assets. For additional depth, CIS 18.2 (external penetration testing) complements manual and automated scanning with penetration testing. This Safeguard validates whether identified vulnerabilities are exploitable in practice. CIS 16.2 (Process to accept and address software vulnerabilities) extends the program for organizations developing or maintaining code repositories. Additionally, CISA's Known Exploited Vulnerabilities (KEV) Catalog serves as a supplemental resource for prioritizing vulnerability remediation on in-scope assets based on real world exploitation activity.

NSF13 maps to CIS 4.1 and CIS 4.2. Each of these relate to the creation of secure configuration processes.

CIS 4.1 instructs organizations to “establish and maintain a secure configuration process for enterprise assets (end-user devices, including portable and mobile, non-computing/IoT devices, and servers) and software (operating systems and applications). Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard.”

CIS 4.2 adds “establish and maintain a documented secure configuration process for network devices. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard.”

We view the differences in language between the NSF Critical Control and the CIS Safeguards as inconsequential (e.g., “create and implement” vs “establish and maintain”; “enterprise assets” vs “systems under direct management”). Organizations need a documented approach to secure configuration that they actually apply to their technologies.

Regarding supporting practices, the remainder of CIS 4's Safeguards are relevant and worth consideration as components of the overarching secure configuration standards/processes. CIS 4.7 warrants particularly strong consideration, as it is among the most empirically-proven controls (see, e.g., the Transformative Twelve). Moreover, implementation of the Trusted CI Framework's Must 3 (Asset Documentation) is foundational for ensuring secure configuration applies to the full range of the organization's technologies.

NSF14 maps to CIS 17.4 and CIS 17.7, with one additional requirement. Each of these relate to cybersecurity incident response.

CIS 17.4 states that organizations should “establish and maintain a documented incident response process that addresses roles and responsibilities, compliance requirements, and a communication plan. Review annually, or when significant enterprise changes occur that could impact this Safeguard.” We draw no particular distinction between NSF14's reference to a “Plan” and the CIS reference to a “documented incident response process.” We also believe that it's entirely appropriate for organizations to document their process across multiple policies, plans, playbooks, and/or other artifacts. We do not interpret NSF14 as requiring a singular “Plan” artifact.

In terms of additional requirements, NSF14 explicitly calls for the documented plan/process to be approved by “Program and facility leadership.” We recommend that organizations require incident response policy and planning approval by the most senior leaders with cybersecurity risk acceptance responsibility.

CIS 17.7 instructs organizations to “plan and conduct routine incident response exercises and scenarios for key personnel involved in the incident response process to prepare for responding to real-world incidents. Exercises need to test communication channels, decision-making, and workflows. Conduct testing on an annual basis, at a minimum.” This directly maps to and expands on NSF14's requirements.

In terms of supporting practices, Must 5 (about senior leadership involvement) and Must 6 (about formalizing risk acceptance roles and responsibilities) directly support the good governance practices necessary not only for IR plan approval but effective and efficient decision making at the time of an incident. Moreover, in the general sense of how policy is defined in the Trusted CI Framework, sound Must 9 policy lifecycle practices will support the development, adoption, explanation, following, enforcement, and revision of the organization's normative IR documentation.

Finally, we encourage organizations to consider the entirety of CIS 17's Safeguards when developing IR processes and plans. All seven of these Safeguards are worth addressing as part of IR planning. They go a long way toward defining what details should be included in solid IR plans.