NIST SP 800-209r1 ipd: Security Guidelines for Storage Infrastructure
Analyze & explore related research in Conceptio
Connect this record directly into your research workflow or AI agent. Explore citations across open repositories, query full text, and export structured proof bundles.
NIST Special Publication 800 NIST SP 800-209r1 ipd
Security Guidelines for Storage Infrastructure Initial Public Draft Ramaswamy Chandramouli Eric A. Hibbard This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-209r1.ipd
NIST Special Publication 800 NIST SP 800-209r1 ipd
Security Guidelines for Storage Infrastructure Initial Public Draft Ramaswamy Chandramouli
Computer Security Division Information Technology Laboratory
Eric A. Hibbard
Samsung Semiconductor, Inc.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-209r1.ipd July 2026
U.S. Department of Commerce Howard Lutnick, Secretary of Commerce National Institute of Standards and Technology Arvind Raman, NIST Director and Under Secretary of Commerce for Standards and Technology
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
Certain equipment, instruments, software, or materials, commercial or non-commercial, are identified in this paper in order to specify the experimental procedure adequately. Such identification does not imply recommendation or endorsement of any product or service by NIST, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose. There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST. Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications. Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST. NIST Technical Series Policies Copyright, Use, and Licensing Statements NIST Technical Series Publication Identifier Syntax Publication History Approved by the NIST Editorial Review Board on YYYY-MM-DD [Will be added to final publication.] Supersedes NIST Series XXX (Month Year) DOI [Will be added to final publication, if applicable.] How to Cite this NIST Technical Series Publication Chandramouli R, Hibbard EA (2026) Security Guidelines for Storage Infrastructure. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-209r1 ipd. https://doi.org/10.6028/NIST.SP.800-209r1.ipd Author ORCID iDs Ramaswamy Chandramouli: 0000-0002-7387-5858 Eric Hibbard: 0009-0001-8112-1263
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
Public Comment Period July 22, 2026 – September 8, 2026 Submit Comments sp800-209r1-comments@nist.gov National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Additional Information Additional information about this publication is available at https://csrc.nist.gov/pubs/sp/800/209/r1/ipd, including related content, potential updates, and document history. All comments are subject to release under the Freedom of Information Act (FOIA).
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1
Abstract
2 3 4 5 6 7 8 9 10
Storage technology has evolved in two primary directions: increased media storage capacity and architectural changes that provide a software-based abstraction over all forms of background storage technologies. However, this architectural shift has increased management complexity and the probability of configuration errors and associated security threats. This document provides an overview of the evolution of the storage technology landscape, current security threats, and the resultant risks to provide a comprehensive set of security recommendations in the form of storage security controls. These recommendations span security management areas that are common to an information technology (IT) infrastructure as well as those specific to storage infrastructure.
11
Keywords
12 13 14
backup; block storage service; cloud storage; data protection; file storage service; hyperconverged storage; network-attached storage; object storage service; replication; softwaredefined storage; storage area network; storage array; storage virtualization.
15
Reports on Computer Systems Technology
16 17 18 19 20 21 22 23 24 25
The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.
i
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
26
Call for Patent Claims
27 28 29 30 31 32 33
This public review includes a call for information on essential patent claims (claims whose use would be required for compliance with the guidance or requirements in this Information Technology Laboratory (ITL) draft publication). Such guidance and/or requirements may be directly stated in this ITL Publication or by reference to another publication. This call also includes disclosure, where known, of the existence of pending U.S. or foreign patent applications relating to this ITL draft publication and of any relevant unexpired U.S. or foreign patents.
34 35
ITL may require from the patent holder, or a party authorized to make assurances on its behalf, in written or electronic form, either:
36 37
a) assurance in the form of a general disclaimer to the effect that such party does not hold and does not currently intend holding any essential patent claim(s); or
38 39 40
b) assurance that a license to such essential patent claim(s) will be made available to applicants desiring to utilize the license for the purpose of complying with the guidance or requirements in this ITL draft publication either:
41 42
i.
under reasonable terms and conditions that are demonstrably free of any unfair discrimination; or
43 44
ii.
without compensation and under reasonable terms and conditions that are demonstrably free of any unfair discrimination.
45 46 47 48 49
Such assurance shall indicate that the patent holder (or third party authorized to make assurances on its behalf) will include in any documents transferring ownership of patents subject to the assurance, provisions sufficient to ensure that the commitments in the assurance are binding on the transferee, and that the transferee will similarly include appropriate provisions in the event of future transfers with the goal of binding each successor-in-interest.
50 51
The assurance shall also indicate that it is intended to be binding on successors-in-interest regardless of whether such provisions are included in the relevant transfer documents.
52
Such statements should be addressed to: sp800-209r1-comments@nist.gov
53
ii
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
54
Table of Contents
55
Executive Summary............................................................................................................................1
56
1. Introduction ...................................................................................................................................2
57 58 59 60 61
2. Data Storage Technologies Background...........................................................................................6
62 63
2.1.1. Storage Area Network (SAN) ........................................................................................................ 7
64
2.1.2. Other Forms of Networked Block Storage ................................................................................... 8
65 66 67 68 69 70 71
2.7.1. Storage Resource Configuration and Resource Management ................................................... 11
72
2.7.2. Data Classification or Categorization ......................................................................................... 12
73
2.7.3. Storage Sanitization .................................................................................................................... 12
74
2.7.4. Data Retention ........................................................................................................................... 12
75
2.7.5. Data Protection .......................................................................................................................... 13
76
2.7.6. Data Reduction ........................................................................................................................... 14
77
3. Threats and Risks .........................................................................................................................15
78 79
3.1.1. Malware Infection and Ransomware ......................................................................................... 15
80
3.1.2. Unpatched Vulnerabilities .......................................................................................................... 16
81
3.1.3. Physical Theft or Inappropriate Disposal of Storage Media ....................................................... 16
82
3.1.4. Platform Security Compromises ................................................................................................. 17
83 84
3.2.1. Data Breach and Data Exposure ................................................................................................. 17
85
3.2.2. Unauthorized Data Alteration and Addition .............................................................................. 18
86
3.2.3. Data Corruption .......................................................................................................................... 18
87
3.2.4. Compromised Data Resilience/Protection ................................................................................. 18
88
3.2.5. Malicious Data Obfuscation and Encryption .............................................................................. 19 iii
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
89
3.2.6. Data Unavailability and Denial of Service................................................................................... 19
90
3.2.7. Compromising Storage OS or Binaries, Firmware, and Images .................................................. 19
91
4. Storage Security Controls .............................................................................................................20
92 93
4.1.1. Policy and Planning (PP).............................................................................................................. 20
94
4.1.2. Documentation and Testing ....................................................................................................... 23
95
4.1.3. Storage Resource Management (SRM) ...................................................................................... 24
96
4.1.4. People Controls .......................................................................................................................... 26
97 98
4.2.1. Physically Secure Storage ........................................................................................................... 27
99
4.2.2. Protect Physical Interfaces ......................................................................................................... 28
100
4.2.3. Isolation of Storage Systems ...................................................................................................... 29
101 102
4.3.1. Storage Systems Hardening........................................................................................................ 31
103
4.3.2. Security Auditing and Monitoring .............................................................................................. 36
104
4.3.3. Storage Vulnerability Management ........................................................................................... 41
105
4.3.4. Storage Accounting and Management ....................................................................................... 41
106
4.3.4.1. Authentication Recommendations ....................................................................................... 41
107
4.3.4.2. Account Management Recommendations ........................................................................... 42
108
4.3.4.3. Privilege and Session Management Recommendations....................................................... 43
109
4.3.4.4. Administrative Access ........................................................................................................... 44
110
4.3.5. Protocols ..................................................................................................................................... 45
111
4.3.6. Storage Platform Security........................................................................................................... 47
112
4.3.6.1. Firmware Security ................................................................................................................. 47
113
4.3.6.2. Debugging/Diagnostic Interfaces.......................................................................................... 48
114
4.3.6.3. Attestation ............................................................................................................................ 48
115 116
4.4.1. Storage Backups ......................................................................................................................... 49
117
4.4.2. Storage Replication and Mirroring ............................................................................................. 50
118
4.4.3. Storage Snapshots ...................................................................................................................... 50
119
4.4.4. Cyber Recovery Systems............................................................................................................. 51
120 121
4.5.1. Block-Based Storage Networking ............................................................................................... 53
122
4.5.1.1. Fibre Channel ........................................................................................................................ 54
123
4.5.1.2. NVMe Over Fibre Channel (FC-NVMe) ................................................................................. 56
iv
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
124
4.5.1.3. IP Storage Networking .......................................................................................................... 56
125
4.5.1.4. NVMe over TCP (NVMe/TCP)................................................................................................ 59
126
4.5.2. File-Based Storage Networking .................................................................................................. 59
127
4.5.2.1. Network File System (NFS).................................................................................................... 59
128
4.5.2.2. Server Message Block (SMB) ................................................................................................ 60
129
4.5.3. Object-Based Storage Networking ............................................................................................. 61
130 131
4.6.1. General Storage Encryption and Key Management Controls .................................................... 63
132
4.6.2. Encrypting Data at Rest .............................................................................................................. 64
133
4.6.3. Encrypting Data in Transit .......................................................................................................... 65
134
4.6.4. Key Management for Storage .................................................................................................... 66
135 136
5. Summary and Conclusions ............................................................................................................69
137
References.......................................................................................................................................70
138
Appendix A. List of Symbols, Abbreviations, and Acronyms ...............................................................73
139
Appendix B. Glossary .......................................................................................................................79
140
Appendix C. Controls List and Mapping of Mitigating Controls to Storage-Oriented Threats ............... 81
141
Appendix D. Change Log ...................................................................................................................87
142
List of Tables
143
Table 1. Comprehensive list of control labels and titles .....................................................................81
144
Table 2. Mapping of storage-oriented threats to mitigating controls .................................................86
145 146
v
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
147
Acknowledgments
148 149 150 151
The authors express their sincere thanks to NetApp, Dell, SNIA, IEEE, Infinidat, FCIA, Center for Cybersecurity Standards at NSA and Richard Austin for their extensive, insightful feedback. Last but not the least, the authors would like to express their thanks to Isabel Van Wyk of NIST for her detailed and extensive editorial review.
vi
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
152
Executive Summary
153 154 155 156 157 158
Storage, computing, and networking form the three fundamental building blocks of an information technology infrastructure. Like computing and network technologies, storage technology has also evolved over the years, specifically higher capacity media and storage system architecture. These architectural developments have enabled storage services to support new computing use cases but have also introduced storage management complexity and many security challenges.
159 160 161 162 163
This document provides an overview of the current storage technology landscape, including traditional storage services (e.g., block, file, and object storage), storage virtualization, storage architectures designed for virtualized server environments, and storage resources hosted in the cloud. It also describes and analyzes various threats and risks to storage resources and infrastructure as well as their impacts.
164 165 166 167 168 169 170 171 172
The primary purpose of this document is to provide a comprehensive set of security recommendations in the form of storage security controls for the current landscape of the storage infrastructure. The security focus areas include those that are common to the entire IT infrastructure, such as physical security, authentication and authorization, change management, configuration control, incident response, and recovery. Within these areas, security controls that are specific to storage technologies, such as network-attached storage (NAS) and storage area networks (SAN), are also covered. In addition, specific security recommendations are provided for the following areas of operation in the storage infrastructure:
173
•
Data protection
174
•
Isolation
175
•
Restoration assurance
176
•
Encryption
177
1
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
178
1. Introduction
179 180 181 182 183 184 185 186
Storage, computing, and networking form the three fundamental building blocks of any information technology (IT) infrastructure. Storage infrastructure has evolved over the years to become feature-rich in areas such as performance and efficiency due to developments on two fronts. One is the area of storage media, which features solid-state drives (SSDs) with high capacity and storage efficiency features (e.g., deduplication, compression) compared to hard disk drives (HDDs). The second is the area of storage system architecture that uses concepts such as storage virtualization. However, development on this second front has also introduced a great deal of management complexity, including the task of providing security assurance.
187 188 189 190 191 192 193 194
Briefly tracing the history of storage system architecture shows that the earliest form of digital storage infrastructure is direct-attached storage (DAS), where the storage element or device (e.g., tape, hard disk) is directly attached to the host server without any intervening network. The next evolution of storage infrastructure is one where the storage resources are logically pooled, located across the network, accessed through networking protocols, and accessible by multiple hosts or servers. This type of storage infrastructure is the only way that the data access needs of distributed systems can be supported since application components that need to share data are in different nodes of a network.
195 196 197 198 199 200 201 202 203 204 205
In this stage of evolution, the storage infrastructure has taken two forms, depending on the type of networking protocol. In one form, the storage resource is simply a node in a network that uses common networking technology (e.g., local area network [LAN], wide-area network [WAN]). An example is network-attached storage (NAS), which provides file-level access to heterogeneous clients across a network using higher level protocols, such as network file system (NFS) or server message block (SMB). In the other form, there is a dedicated network for communicating with all storage resources. This is exemplified by the storage area network (SAN), an implementation of which uses a specialized, high-speed network (e.g., Fibre Channel) that provides block-level access to storage. Another implementation of a SAN uses the Internet Small Computer Systems Interface (iSCSI) protocol over a possibly shared LAN/WAN infrastructure.
206 207 208
The next wave of storage evolution involves the introduction of cloud storage, which offers a highly scalable and durable set of storage services that are completely software-defined. Cloud storage services often include:
209 210
•
Block storage services, which expose software-defined block devices that can be presented to virtual hosts running in the cloud
211 212 213
•
Object storage services, which can be mapped to hosts, applications, or even other cloud services and allow for addressing discrete, unstructured data elements by ID or metadata
214 215
•
Scalable shared file systems, which can allow a scalable set of hosts to access the same file system at a high speed
216 217
•
A variety of replication, caching, mirroring, and point-in-time copy services to all of the above
2
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
218 219 220 221 222 223
Another type of storage infrastructure contains interfaces to support the data storage needs of emerging stateful applications that are designed using microservices-based architecture and deployed using containers organized into clusters with container orchestration platforms. These platforms have a standard plug-in mechanism by way of a container storage interface (CSI) that connects the clusters configured by them to different types of persistent storage implementations.
224
1.1. Scope
225
This document provides security recommendations for the following storage technologies:
226 227
•
Traditional enterprise storage technologies classified by storage service interface type (e.g., block, file, object)
228
•
Network-based storage (e.g., NFS, SAN)
229 230
•
Storage systems that have a layer of software abstraction (e.g., software-defined storage, storage virtualization)
231 232 233
•
Storage systems designed exclusively for virtualized server environments (e.g., storage for virtual machines [VMs] and containers, converged and hyperconverged storage systems)
234 235
•
Storage systems designed with Application Programming Interfaces (APIs) for cloud access
236
The security recommendations span the following operations:
237 238 239 240
•
Operations that are carried out for other infrastructures (e.g., computing, networking) in which specific tasks are applicable to storage infrastructure, such as physical security, authentication and authorization, audit logging, network configuration, isolation, configuration control, change management, and training
241 242
•
Operations that are unique to storage infrastructure, such as data protection and restoration assurance
243
Storage infrastructure for mainframes is out of scope for this document.
244
1.2. Target Audience
245
The target audience for the security recommendations discussed in this document includes:
246 247 248 249
•
The Chief Security Officer (CSO) or Chief Technology Officer (CTO) of an IT department in a private enterprise, government agency, or cloud service provider who wishes to formulate enterprise- or data center-wide policies for the entire infrastructure, including storage infrastructure
250 251
•
System or storage administrators who set up specific deployment configurations for storage, converged, or virtualized systems
3
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
252
1.3. Relationship to Other NIST Documents
253 254 255 256 257 258 259 260
This document focuses on a particular type of infrastructure that provides access to all data resources and services, similar to how the computing infrastructure provides access to computing services and the networking infrastructure provides access to communication services. Hence, some security recommendations related to computing and networking are relevant security strategies for the storage infrastructure discussed in this document. These common recommendations are either included here with a brief description or incorporated by reference. The relevant NIST documents containing recommendations that span all infrastructures (i.e., computing, networking, and storage) are:
261 262
•
Special Publication (SP) 800-52r2 (Revision 2), Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations (2019)
263 264
•
SP 800-53r5, Security and Privacy Controls for Information Systems and Organizations (2020)
265
•
SP 800-57pt1r5 (Part 1), Recommendation for Key Management: Part 1 – General
266
•
SP 800-63A-4, Digital Identity Guidelines: Identity Proofing and Enrollment (2025)
267 268
•
SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (2025)
269
•
SP 800-88r2, Guidelines for Media Sanitization (2025)
270
•
SP 800-125Ar1, Security Recommendations for Server-based Hypervisor Platforms (2018)
271 272
•
SP 800-125B, Secure Virtual Network Configuration for Virtual Machine (VM) Protection (2016)
273
1.4. Document Organization
274
The organization of this document is as follows:
275 276 277 278
•
Section 2 provides an overview of traditional enterprise storage technologies, storage access technologies that provide a level of abstraction, storage architectures tailored for virtualized server environments, and storage resources in the cloud. This section also describes certain general principles of storage administration.
279 280 281 282 283 284 285
•
Section 3 explores threats to storage infrastructure and associated risks, such as unauthorized storage configuration changes, media theft, and insecure storage images. The resulting risks to storage infrastructure (e.g., data breach or exposure, unauthorized data alteration and addition, data corruption, data obfuscation and encryption, tampering of storage-related log and audit data, compromising backup and firmware) are also analyzed based on the possibility of the realization of these threats and their impacts.
286 287
•
Section 4 provides security recommendations in the form of storage security controls for all facets of storage infrastructure management.
4
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
288
•
Appendix A provides a list of acronyms used throughout this document.
289
•
Appendix B provides a glossary of important terms used throughout this document.
290 291
•
Appendix C provides a summary of the controls as well as mapping of the mitigating controls to the storage-oriented threats.
292
•
Appendix D provides a summary of the changes for this version of NIST SP 800-209.
5
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
293
2. Data Storage Technologies Background
294 295 296 297
Data storage technology encompasses the devices, objects (e.g., storage arrays, network switches, media), and processes (e.g., protocols, interfaces) used to store computer data in non-volatile (i.e., durable) form. Hence, this technology can be viewed from the following two taxonomies:
298 299 300
•
Based on the location of a storage resource: The storage device is either directly attached to the storage client or host computer (i.e., DAS), or there is a network separating the host computer and the storage device (i.e., networked storage).
301 302 303 304
•
Based on storage type (access type): This classification is based on the service interface offered by the storage system that is used by the client software. Examples include block-based storage (i.e., block storage service), file-based storage (i.e., file storage service), and object-based storage (i.e., object storage service).
305 306
In DAS, the storage device can be either an integral part of the computer (attached to the bus) or external storage (attached to a computer port, such as serial or USB).
307 308 309 310 311 312 313 314
Networked storage is broadly classified based on the type of access. For example, NAS provides file-level access across the network, and SAN’s protocols provide block-level access across the network. Furthermore, in SAN, either the entire network stack can be comprised of storagespecific protocols (e.g., Fibre Channel), or it can consist of storage-specific protocols running over or encapsulated within common networking protocols (e.g., iSCSI by design running over Transmission Control Protocol/Internet Protocol [TCP/IP], Fibre Channel over IP [FCIP], cloud block storage). In networked storage, remote storage devices are presented as if they are locally attached to the host system on which the storage client software is running.
315 316 317 318 319
The taxonomy based on storage, access, or service type includes block, file, and object types or services. Since the choice of a storage service is dictated by the specific IT system use case (e.g., volume of data, control over data, performance, nature of data representation), this document will present an overview of storage technology in terms of these services (synonymous with storage/access types).
320 321
The data storage media landscape is constantly evolving and includes many technologies, such as:
322
•
Magnetic (e.g., spinning disk drives, tapes)
323
•
Optical (e.g., CD-R, DVD-R, Blu-ray) and magneto-optical
324
•
Semiconductor (e.g., SSD, flash drives, persistent memory devices)
325
•
Hybrid (e.g., devices that incorporate both magnetic and semiconductor technologies)
326 327
Experimental and less prevalent technologies include molecular memory (e.g., polymer-based), holographic (e.g., crystal-based), and DNA-like.
6
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
328
2.1. Block Storage Service
329 330 331 332
A block storage service offers an interface that reads and writes fixed-size blocks of data, typically with high-bandwidth and low-latency access to storage devices at the block level. Each storage device in a block-level storage system can be controlled as an individual hard drive, and the blocks are managed by the host operating system (OS).
333
2.1.1. Storage Area Network (SAN)
334 335 336 337 338 339
The building blocks of SAN-based systems typically include (a) host computers (clients); (b) topology, which involves the distribution of switches; and (c) storage devices/arrays. All three components are interconnected using various network stacks. SAN is a specialized, high-speed network for block-level network access to storage [1], and its variants are the results of different types of network stacks with different protocols in certain layers of the stack. There are several SAN protocols, including:
340
•
Fibre Channel SAN (FC SAN)
341
•
IP SAN
342
•
Protocols of Non-Volatile Memory express (NVMe) over fabrics (NVMe-oF)
343 344 345 346 347 348 349
An FC SAN is a network stack that uses the Fibre Channel protocol with five layers (i.e., FC-0 through FC-4, unlike the seven-layer Open Systems Interconnection [OSI] stack). The logical storage resource addressed by Fibre Channel SAN is called the logical unit number (LUN). IP SAN is a network stack that uses the IP protocol at the network layer. iSCSI is an example of IP SAN. Although such use is technically inaccurate, a block device in an FC SAN or IP SAN is often referred to as “LUN.” The historical roots of the term stem from SCSI logical unit numbers (LUNs) that were carried along to SANs.
350 351 352 353 354
NVMe is the standard host controller interface for systems that use PCI Express (PCIe)based SSD. The NVMe over Fabrics (NVMe-oF) specification defines a protocol interface and related extensions that enable the NVMe commands to be transmitted over the network. Thus, NVMe-oF extends the NVMe deployment from a local host to a remote host for a scale-out NVMe storage system.
355 356 357 358 359 360 361
The protocols of NVMe-oF include Remote Direct Memory Access (RDMA) (a family of protocols), Fibre Channel, and TCP. RDMA [4] enables server-to-server data movement directly between application memory without any CPU involvement, thus allowing a local application to read or write data on a remote computer’s memory with minimal demands on memory bus bandwidth and CPU processing overhead while preserving memory protection semantics. Infiniband [5] is one of the industry standard interconnects that enables RDMA for highperformance computing (HPC) environments.
362 363 364 365
The topology of the nodes together with the various hardware elements in a SAN system are called the SAN fabric. For example, a Fibre Channel SAN fabric consists of a Name Server (NS) that registers and communicates with switches and end points (i.e., host bus adapters [HBAs]). There are two commonly used topologies in FC SAN: point-to-point (two devices are directly
7
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
366 367 368
connected) and switched fabric. In switched fabric, there is a set of hardware switches acting as one big logical switch that connects the host computer and the storage resources. Security recommendations in this document cover only this commonly deployed topology.
369
2.1.2. Other Forms of Networked Block Storage
370
Other forms of block storage that can be presented to hosts over IP networks include:
371
•
Cloud block storage service, which is offered in all cloud environments (see Sec. 2.6)
372
2.2. File Storage Service
373 374 375
This type of service presents storage resources in a file system model with files contained in directories within volumes. Files can be replicated by making redundant copies or be encrypted. The different variations of this service and their associated protocols are:
376 377 378 379 380
•
NAS with Network File System (NFS) protocol [6]: A module that is part of the protocol implementation system (NFS client driver) mounts the volumes that are relevant for the client in its environment. The volume can be shared by multiple clients. The files or folders can also be shared from either a dedicated appliance (“NAS device” or “NAS array”) or from any host running the NFS server service.
381 382 383
•
NAS with SMB protocol connection: This is provided by a LAN-attached file server, like those that provide NFS protocol connections, but with the standard SMB protocol that is found in the network stack of OSs used in personal computers and workstations.
384 385 386 387 388
•
NAS with multi-protocol support: There are file service storage offerings that support multi-protocol exports of a folder or file system (e.g., both NFS and SMB, concurrently). Each of these can have slightly different access control structures (i.e., access control list [ACL]/permission specifications), and some conflicts in access control rights may have to be resolved during access requests.
389 390 391 392 393 394 395 396 397 398 399
•
NAS with parallel NFS protocol (pNFS): This is provided through a clustered collection of storage servers that slices and/or strips data and metadata at the back end while providing dynamic, distributed client connections at the front end across the set of clustered hosts. The pNFS is implemented by either (a) partitioning file system namespace and assigning storage resources (i.e., files) that belong to different namespaces to different servers (symmetric clustering) or (b) splitting functionality across servers (asymmetric clustering) by having a primary fileserver provide the directory information for the location of secondary storage servers, the data contained in them, and the method for accessing them. This service is used for large-scale content repositories (because of its scalability), media stores, and development environments [7].
8
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
400
2.3. Object Storage Service
401 402 403 404 405 406
An object storage service presents data as flexible, discrete buckets or containers that store objects. Unlike the fixed-size blocks offered by a block storage service or the directories and subdirectories of a traditional file system or NAS service, each object can be of arbitrary size and is assigned a unique identifier (an object ID number or OID) that is compiled with other OIDs into a flat index used to access the data in each object. In addition, dynamic metadata can also be attached to an object to facilitate flexible search and addressing.
407 408 409 410 411 412
The primary benefit of object storage is scalability since its flat index is more efficiently searched than a traditional file system. With only an OID needed to search for data (plus an offset into the object itself), lookups are essentially a two-step process versus the multiple steps used to walk the directory tree of a traditional file system. The immediate effect of this is a reduction in metadata handling by the storage system, which means faster file access, especially as the system grows to very large proportions.
413
2.4. Storage Virtualization
414 415 416 417 418 419 420 421 422 423
Storage virtualization is the act of abstracting, hiding, or isolating the internal function of a storage (sub) system or service from applications, compute servers, or general network resources for the purpose of enabling independent application and network management of storage or data. Storage virtualization allows multiple storage devices or arrays to be pooled (abstracted) so that they can be managed as one entity. Virtualization can aggregate and manage storage resources as logical storage across a wide range of physical storage devices in large networks (e.g., SAN) or data centers. Virtualization also allows for segregating a storage resource or pool to multiple virtual representations of such resources. This technique provides the flexibility to change the logical to physical relationship over time and mask the details of physical storage resources [10].
424
The following are example scenarios in which storage virtualization is deployed:
425 426 427 428
•
Portions of multiple physical disk drives can be presented as a single mirrored logical volume using a logical volume manager (LVM) in a host or storage array. The composition of physical disk drives in the mirrored volume can be changed, and devices can be written concurrently on both mirrors (“active-active”).
429 430 431
•
Sensing changes to access patterns, the drives on which data is stored can be changed (e.g., store frequently accessed data on high performance drives) to provide an automatic tiering functionality.
432 433
•
Large-scale data migrations need to be performed transparently to hosts and applications.
434 435
The benefits of storage virtualization are scalability, performance, redundancy, and increased storage resource utilization.
9
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
436
2.5. Storage for Virtualized Servers and Containers
437 438 439
A virtualized server is one in which a single physical server runs multiple computing stacks that consist of an OS, storage, network, and applications. These virtual machines (VMs) use software called a hypervisor.
440 441 442 443 444 445 446 447 448
Containers offer a lighter form of packaged compute, network, and storage units. Multiple containers can run on a server, a VM, or specialized clusters that provide orchestration services. Persistent storage for containers [14] is provided by creating volumes through a new file directory that is local to the host on which the container is running or through mapping to an external SAN or NAS device using plugins. These volumes can be created ahead of time or at when the container starts and can be shared by multiple containers. Plugins are provided by storage vendors to facilitate the process of volume creation while conforming to the specification of the container engine/orchestrator. Plugins automate the process of LUN/volume creation as well as mapping to the host and, eventually, the container.
449
2.6. Cloud-Based Storage Systems
450 451 452
Storage systems in the cloud may be either standards-based or proprietary and may include object-, block-, or file-based services. The technical reasons for enterprises to use storage systems in the cloud are [20]:
453 454
•
To accommodate new demand for storage resources without building an additional data center
455
•
To respond to changes in demand for storage, such as peaks and valleys
456
•
The need for immediate storage capacity
457
•
Increasing management complexity of on-premises storage infrastructure
458
Storage systems based in the cloud provide several sophisticated data services [21], including:
459 460 461
•
Collaboration capability: Includes features such as (a) notifications when files are changed by others, (b) file sharing with the ability to set editing and view-only permissions, (c) simultaneous editing, and (d) change tracking and versioning.
462 463 464
•
Data integration and analytics capability: Ability to integrate data resident on several cloud sources, perform complex analytics, and either instantly serve the extracted data or store it in a persistent storage for later access by cloud service customers.
465 466
•
Advanced data protection services: Includes replication, mirroring, auditing, and encryption.
467
Cloud storage services often include:
468 469
•
Block storage services that expose software-defined block devices that can be presented to virtual hosts running in the cloud
470 471
•
Object storage services that can be mapped to hosts, applications, or even other cloud services 10
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
472 473
•
Scalable shared file systems that can allow a scalable set of hosts to access the same file system at a high speed
474 475
•
A variety of replication, caching, mirroring, and point-in-time copy services to all of the above
476 477 478 479
Additional cloud services (e.g., managed database services, data lakes, memory caches, messages queues) may also be offered, all of which can store stateful and transient data. However, experts are divided over whether to classify them as storage services in and of themselves.
480
2.7. Storage and Data Management
481 482 483
Storage management refers to all activities geared toward ensuring reliability, resilience, performance, and the security of storage resources through management tools and processes. Non-security control-related activities that are followed as a state of practice are:
484
•
Storage resource configuration and resource management
485
•
Data classification or categorization
486
•
Storage sanitization
487
•
Data retention
488
•
Data protection
489
•
Data reduction
490
2.7.1. Storage Resource Configuration and Resource Management
491 492
Storage resource configuration and resource management involve the complete life cycle management of storage infrastructure and include:
493 494
•
Management and control of physical storage devices, such as storage arrays, SAN switches, software updates, device configuration, and device onboarding and disposal
495
•
Change orchestration across multiple assets
496 497 498
•
Management of storage resources (e.g., block device, filesystems, pools), including assignment to hosts, replication, point-in-time copy management, data migration, and data tiering
499
•
Performance management and optimization
500
•
Capacity management and optimization
501
•
Inventory management
502
•
Event management
11
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
503
2.7.2. Data Classification or Categorization
504
Enterprise data can be classified along several dimensions, such as:
505
•
Sensitivity (e.g., sensitive versus non-sensitive)
506
•
Frequency (e.g., frequently accessed versus non-frequently accessed)
507
•
Environment (e.g., production versus development versus testing versus staging)
508 509 510 511 512 513 514 515 516 517
Sensitivity classification is necessary to enable the provisioning of appropriate security controls (e.g., authentication, authorization, encryption, key management, sanitization). Furthermore, the sensitivity category may have sub-categories based on regulations applicable to the data, such as personally identifiable information (PII), Health Insurance Portability and Accountability Act (HIPAA)-related, and the Payment Card Industry Digital Security Standard (PCI-DSS). Frequency classification is necessary to provision the appropriate storage media (e.g., SSD versus HDD). The environment classification may be relevant for both media selection and security controls. Other classification schemes based on project, application, or other factors may exist but are not listed here since they do not necessarily have security control implications.
518
2.7.3. Storage Sanitization
519 520 521
Storage sanitization is the process of rendering previously written data irretrievable, such that there is reasonable assurance that the data cannot be accessed or reconstructed [10]. There are three methods for sanitization:
522
•
Clear (e.g., overwriting existing data)
523 524
•
Purge (e.g., using a strong magnetic field for magnetic media degaussing, cryptographic erase for encrypted data)
525
•
Destruct (e.g., incineration, pulverizing)
526 527 528
Factors that determine the appropriate type of sanitization include the category of data on the media, the nature of the media (e.g., solid-state, magnetic, optical), and reuse plans for the media.
529 530 531 532
Sanitization can be applied to individual storage media or to logical data (e.g., in the cloud). To achieve its goals, sanitization must consider the type and characteristics of media. For example, overwriting data is effective on magnetic disks but not on SSDs that use flash memory because those devices do not overwrite data in place.
533
2.7.4. Data Retention
534 535 536 537
There may be situations in which preserving access to particular data is needed for a short/medium-term (i.e., less than 10 years) or long-term duration. This retention may be due to operational, legal, regulatory, or statutory obligations. Short/medium-term retentions are often handled within storage infrastructures using immutability technologies or locking
12
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
538 539
approaches that prevent changes to data. Long-term retentions often involve specialized services, such as archives or cloud storage.
540 541 542 543 544 545
Immutability involves the ability to prevent data destruction or alteration along with integrity verification (e.g., hashing), and the enforcement of explicit retention periods (e.g., legal holds). To meet immutability (non-editable) requirements, organizations often use “write once, read many” (WORM)-based storage or object-based storage implementations that combine WORM with metadata that can be used to perform explicit integrity checks and enforce data expirations.
546
2.7.5. Data Protection
547 548 549 550 551
Data protection refers to activities that ensure that data is accessible, usable, uncorrupted, and available for all authorized purposes with an acceptable level of performance and is handled in accordance with compliance obligations, including privacy and all physical, administrative, and technical means, to provide assurance against accidental or unauthorized disclosure, modification, or destruction.
552
Data protection involves activities and mechanisms that span the following [22]:
553
•
Data at rest/at the endpoint: On a server or client device
554
•
Data in transit: Between storage devices, client to server, or server to server
555
•
Data in use: While viewing, modifying, or synchronizing between devices
556 557 558 559 560
The range of objectives and associated activities provides a taxonomy for classifying data protection activities under three facets: storage, privacy, and information assurance/security [22]. Activities related to information assurance/security are predominantly technical controls that each require a dedicated section to discuss their details. Hence, this section only discusses storage-related data protection activities and controls. This category of controls includes:
561
•
Data backup and recovery
562
•
Replication and resilience technologies
563
•
Immutability
564
•
Point-in-time copies and snapshots
565 566 567 568 569 570 571
Backup is an operation wherein data stored in storage devices is accessed by production systems and periodically copied to another set of storage devices (some of which may be offline). Because of the changing nature of data content, a backup taken at an earlier time is often made obsolete by a backup taken at a later time. Backups can either be “file backups,” which back up a select portion of the data in a storage device (often based on logical data structures, such as files, directories, or data under a database schema), or “image backups,” which contain the entire content of a particular device (e.g., an individual LUN).
572 573 574
Data replication is the process of writing the same data to at least two separate locations [20]. Replication is often used as part of the data recovery process and involves copying data from one site to another. Generally, there are two types of replication: synchronous and 13
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
575 576
asynchronous. Synchronous replication involves the real-time copying of data from site A (e.g., a production platform) to site B (e.g., a specially designated disaster recovery [DR] site).
577 578 579 580
Asynchronous replication involves time delay and may be performed continuously or using a designated frequency for writing data from site A to site B. The time delay and frequency are dictated by the enterprise’s disaster recovery policy and are described in terms of specific recovery time objective (RTO) and recovery point objective (RPO) goals.
581 582 583 584
Point-in-time copies are usually created by the immediate element storing the source data (e.g., storage array, file system, database) and are designated for fast recovery and a wide variety of other uses, such as cloning production data for testing purposes. Point-in-time copies can also be taken from remote replicas and referred to as “remote point-in-time copies.”
585 586 587 588 589
A snapshot is a storage-efficient form of a point-in-time copy that stores only the individual portions of the data changed (the delta) from a given point in time in reference to the source data (the base). This allows the current state of the data to be recreated from the base by applying the snapshot. This often means that if the base is unavailable, the snapshots will be unusable.
590
2.7.6. Data Reduction
591 592 593
Data reduction is the process of reducing the amount of data stored and/or transmitted in an effort to reduce costs and improve efficiency. Two common approaches to data reduction are data deduplication and compression, which can be used together.
594 595 596 597 598 599 600 601
Lossless data compression (sometimes performed on hardware) seeks to reduce the amount of data by applying a known algorithm to produce a representation of data that uses less storage than the unencoded representation [10] with the property that the compressed version can be uncompressed to restore the original representation of the data. Data compression is most commonly used as part of tape backups and during remote data replication in network gateways to reduce the bandwidth needed for DR and business continuity (BC) operations. Interoperability is an important aspect of data compression since compression and subsequent decompression may be performed by different entities.
602 603 604 605 606
Data deduplication attempts to replace multiple copies of data with references to a shared copy by eliminating identical blocks of storage. For example, if a storage system has 500 identical blocks, the storage array will store just one copy, thereby eliminating the need to store the other 499 copies [20]. This can take place at the storage device level, the transmission stage, or the file system level.
14
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
607
3. Threats and Risks
608 609 610 611 612
SP 800-30r1 [21] provides guidelines on conducting risk assessments for federal information systems and organizations and amplifies the recommendations in SP 800-39 [22] and ISO/IEC 27005 [23]. The risk management strategies described in these documents address how organizations intend to assess, respond to, and monitor risk by making risk perceptions explicit and transparent.
613 614
This section provides background information regarding storage system security threats and risks.
615
3.1. Threats
616 617 618 619
A threat is the potential cause of an unwanted incident, which can result in harm to a system or organization. Storage systems and storage ecosystems are subject to many of the same threats as other elements of ICT. To gain an understanding of these threats, the following sections of SP 800-30r1 [21] should be consulted:
620
•
Appendix D — Potentially relevant threat sources
621
•
Appendix E — Potentially relevant threat events
622
•
Appendix F — Potentially relevant vulnerabilities and predisposing conditions
623
•
Appendix G — Potentially relevant likelihoods of threat event initiation/occurrence
624 625
•
Appendix H — Potentially relevant adverse impacts to organizational operations and assets
626
•
Appendix I — Potentially relevant adversarial and non-adversarial risk determinations
627
The following are examples of generic threats that are particularly relevant to storage systems:
628
•
Credential theft or compromise (e.g., SP 800-63)
629
•
Flawed encryption and/or key management implementations (e.g., SP 800-57pt1r5)
630
•
Exposure of sensitive data while in- transit (e.g., no end-to-end encryption)
631 632
•
Patch management problems (e.g., patches have to come from the vendor, which can be slow to provide updates; regression testing can be complex)
633 634
•
Inappropriate privileged access controls can result in severe consequences to due to attacks or mistakes and damage data
635
The following sections provide a brief overview of threats related to storage infrastructure.
636
3.1.1. Malware Infection and Ransomware
637 638 639
Malware is the general term for any software that is designed to damage, disrupt, or provide means to compromise a system, device or service. Malware compromises exploit a vulnerability (either social or ethical) to gain access, elevate privileges, install other malicious software (e.g., 15
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
640 641 642 643 644
a persistent back-door), etc. Results of successful compromise can include data theft, gaining control of a device or system, and harvesting system resources for unauthorized activities. It can be installed on privileged targets such as a storage management host and then abuse that privileged target to cause harm, such as credential theft, privilege escalation, data corruption, loss or alteration, and the compromise of future backups.
645 646 647 648 649 650
Ransomware is a form of malware that encrypts stored data, rendering it unusable. The adversary then typically demands a ransom to restore access to the data upon payment. Increasingly, adversaries recognize that organizations have recovery mechanisms in place to mitigate ransomware attacks, so prior to encrypting data, some adversaries will exfiltrate data with an intention to publish confidential data that was collected from the storage system if the ransom is not paid.
651
3.1.2. Unpatched Vulnerabilities
652 653 654 655 656
As with all ICT, unpatched vulnerabilities can be used directly or indirectly to bypass other security controls. Exploitable vulnerabilities on management interfaces can allow adversaries to reconfigure systems such that an organization temporarily loses access to its data or the data can be destroyed. Exploitable vulnerabilities on data access mechanisms of storage systems can result in authorized access to sensitive data.
657 658 659 660 661 662 663 664 665 666 667 668
Once vulnerabilities are known — and especially if they are discovered in software versions that are still publicly supported — vendors typically issue a software fix in the form of a patch or a new version to remediate the vulnerability. The timely deployment of such fixes is of paramount importance as adversaries tend to exploit the window of vulnerability between when a vulnerability is announced and when the fix is installed. A large portion of successful attacks are based on vulnerabilities for which a fix has already been published. For some storage systems (particularly those based on open-source software), generic patches for vulnerabilities cannot be directly applied because they may cause unpredictable behaviors on the affected storage system (which may include proprietary enhancements to the underlying open-source software) or potentially void warranties. Approved vendor-supplied patches can be slow to arrive, so interim remediations (e.g., disabling a vulnerable service) may be necessary while awaiting the delivery of patches.
669
3.1.3. Physical Theft or Inappropriate Disposal of Storage Media
670 671 672 673 674 675 676
All data is ultimately stored in one or more copies on physical media, which is susceptible to theft. Media, whether online or offline, can be removed from its designated stationary location or while being physically transported between locations (e.g., backup media being transported for off-site storage, storage equipment being shipped as part of a data center relocation project). Theft can be opportunistic (e.g., the content of the stolen media is not known in advance or targeted), or specific data may be of interest to perpetrators who have the means to determine which media to seize.
677 678
An organization may choose to dispose of storage media by charitable donation, internal or external transfer, or recycling if that storage media is not needed, obsolete or no longer usable. 16
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
679 680
Security Guidelines for Storage Infrastructure
Without appropriate storage sanitization, sensitive data may be exposed to unauthorized parties.
681 682
3.1.4. Platform Security Compromises
683 684 685 686 687 688 689 690 691 692 693 694
Adversaries can attempt to interfere with a storage device’s software distribution, update, or installation process in order to introduce incorrect, outdated, or maliciously modified code (e.g., binaries, images, firmware, drivers). Affected storage components can include disk drives, tape drives, libraries, network cards and controllers (e.g., HBAs, network interface cards, NICs), switches, and storage enclosures and arrays. Software update processes can rely on complex delivery chains (e.g., vendor, third party, open-source community), delivery methods (e.g., transmission or download, shipping of installation media, file copy by vendor employee), and local copies kept by an individual organization (e.g., proxies, internal file servers). Each link in the chain can be targeted to introduce tampered software and affect platform security. Issuers, for example, can be infiltrated to infect source-code libraries, obtain access to signing software or equipment, and publish altered signed binaries on their download sites or update servers. A variety of other strategies can be devised to compromise other links in the chain.
695
3.2. Risks to Storage Infrastructure
696 697 698 699
The threats described in Sec. 3.1 can give rise to a wide range of risks. For storage systems and infrastructure, the major concerns are the risks associated with data breaches, data corruption or destruction, temporary or permanent loss of access/availability, and the failure to meet statutory, regulatory, or legal requirements [6].
700
3.2.1. Data Breach and Data Exposure
701 702 703 704 705 706 707 708
A data breach 1 is an incident that involves sensitive data being copied, transmitted, viewed, deliberately exposed to the public, or used by unauthorized individuals or entities. Data breaches can be exercised by an external source (e.g., adversary) or an internal one (e.g., malicious insider, disgruntled employee). They can be performed in a covert manner with traces being concealed or entirely removed or in a manner that can be easily identified (e.g., due to a lack of sophistication). The impact of data breaches can span a wide range, from inconvenience to users to the devastating exposure of sensitive or confidential data, resulting in irreparable damage to the reputation and operational health of the organization.
709 710 711 712
While certain data breaches involve a high degree of sophistication, many are made possible due to simple, inadvertent security settings of data assets. Among the many possible rootcauses are weak (or absent) encryption at rest or in transit, software flaws, the loss of custody of removable media, media theft, incorrect or relaxed access limitations, improper or 1 ISO/IEC 27040 [6] defines a data breach as a compromise of security that leads to the accidental or unlawful destruction, loss, alteration,
unauthorized disclosure of, or access to protected data transmitted, stored, or otherwise processed. This document takes a narrower perspective.
17
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
713 714 715 716
incomplete data sanitization implementation (e.g., deleted objects, retired or repurposed media), sending or transmitting data to the wrong recipient, or data being uploaded to an incorrect location or in an incorrect manner (e.g., uploading protected data to a public data store).
717
3.2.2. Unauthorized Data Alteration and Addition
718 719 720 721 722 723 724
Data alteration refers to the process of modifying data before or after it is entered into the system. In this case, the adversary gains access to the data storage infrastructure and modifies the data in a way that will affect future application transactions or other uses of the data. Data alteration and addition can be exploited by an external or internal source in a covert or easily identifiable manner. The perception of unauthorized data alteration or addition can be sufficient to render data suspect and unusable. The impacts of data alteration and addition can range from the loss of funds to permanent damage to reputation and trust.
725
3.2.3. Data Corruption
726 727 728 729 730 731 732 733 734 735
Data corruption refers to damage to or errors in data that occur during writing, reading, storage, transmission, or processing and that introduce unintended changes to the original data. An object that contains corrupted data can produce unexpected results (e.g., minor losses, system crash) when accessed by a system or related application. For example, if a document file is corrupted, a user may be unable to open it, or it might open with some or all of the data rendered unintelligible. Some types of malware can intentionally corrupt or destroy files as part of their payloads, usually by overwriting them with meaningless data or otherwise securely erasing their content. While some forms of data corruption will result in storage device, OS, or software errors upon access, others can be designed to affect data without issuing errors.
736
3.2.4. Compromised Data Resilience/Protection
737 738 739 740 741 742 743 744 745 746 747 748 749
Backing up or retaining copies (including replicas and snapshots) of data assets is important to enable their recovery if they are damaged or lost. Satisfactory recovery is possible only if the backup copies are generated correctly with an appropriate retention and currency, stored securely, and accessible in a manner that supports timely restoration. Since these prerequisites closely depend on each other, backups are sensitive to multiple failures. For example, incorrect configuration can involve a live database backup performed without applying techniques to ensure consistency or write-order fidelity. Insufficient currency or retention can mean that at least some portion of the data will be unrecoverable. An adversary, therefore, has a high motivation to target not only a primary data asset but also its backup and copies. When existing copies cannot be compromised, another viable attack strategy can be to interfere with the backup process itself, thereby gradually “poisoning” future copies. When enough time has passed, the adversary can return to the original goal of compromising the primary data assets, knowing that the only available copies for recovery are too old.
18
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
750 751 752 753 754 755
Another type of “poisoning” strategy is to specifically infect backup copies of compute or application assets, such as OS images, software packages, firmware, or even source code repositories. This way, when an individual component or even an entire environment is rebuilt in an attempt to battle a malware infection, at least some portions of the malware will be included in the restored environment, allowing the adversary to quickly regain control or inflict more damage.
756
3.2.5. Malicious Data Obfuscation and Encryption
757 758 759 760 761 762 763 764 765
The malicious use of reversible obfuscation or the encryption of data can result in data becoming unavailable to the user or organization unless it is recovered using information (e.g., a key) held only by an adversary. This type of risk is commonly used in ransomware attacks (see Sec. 3.1.1). Although it originally targeted data or files on users’ computers or enterprise servers, ransomware has evolved to also include other storage components, such as NAS and backup appliances]. Data obfuscation and encryption typically originate from an external source but can also be inflicted by an internal one. These attacks are often accompanied by a threat and ransom instructions. The impacts of data obfuscation and encryption can range from the loss of funds to permanent damage to reputation and trust.
766
3.2.6. Data Unavailability and Denial of Service
767 768 769 770 771 772 773 774 775 776
In a data availability or denial-of-service incident, the data user cannot gain access to some or all of their data due to purposeful or unintended damage to the communication path or access configuration. The damage can be physical (e.g., disconnection along the communication path) or logical (e.g., misconfiguration of an endpoint of network components). Although the damage may be reversible (e.g., by restoring the settings that were altered or deleted), it can cause lengthy disruptions and downtime for the system or service. A DoS attack can also cause disruptions to data availability by flooding the targeted storage devices, management interfaces, clients, or network with superfluous requests in an attempt to overload systems and prevent some or all legitimate requests from being fulfilled. DoS attacks can potentially impact individual data assets and clients as well as the entire fabric.
777
3.2.7. Compromising Storage OS or Binaries, Firmware, and Images
778 779 780 781 782 783 784 785 786
The compromise of storage software (e.g., storage device OSs, firmware, images) can produce a wide range of undesirable outcomes, such as providing adversaries with a means for remote access to read, copy, alter, or destroy data and data copies; change security settings; expose data; or alter the behavior of the storage infrastructure. Storage behavior alteration is of particular concern as it can be used to introduce a variety of latent, hard-to-detect attack capabilities, including presenting incorrect data to storage clients (even if stored data is intact), providing an incorrect status (e.g., falsely reporting the existence or state of snapshots and security settings), bypassing environmental safeguards (e.g., thermal, power consumption, speed limits), or stripping or altering encryption.
19
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
787
4. Storage Security Controls
788 789 790 791 792 793 794 795 796 797 798 799 800 801
The following subsections provide security recommendations and guidelines for storage infrastructure. Each section is dedicated to a specific aspect of storage security with a uniquely identifying naming convention and numbering scheme. Primary unique identifiers take the form ‘xxxx-ss-Cyy’, where ‘xxxx’ is a four-letter combination that relates to the subsection’s heading; ‘ss’ is a two-letter combination that relates to the subheading within the subsection; and ‘yy’ is a sequential numerical identifier preceded by letter ‘C’ standing for control. Those controls that do not have a subheading will carry the two-letter ‘GN’ standing for generic control. For example, in Sec. 4.2.1, “Physical Controls for Data Storage” and subsection “Physically Security Storage,” primary identifiers are labeled PSDS-PS-C03, PSDS-PS-C04, and so forth. Secondary alphabetical identifiers (i.e., ‘(a)’, ‘(b)’, …) are sometimes used to address an entire compound guideline by its primary identifier (e.g., ‘PSDS-PS-C03’ to address media security) as well as specific portions thereof (e.g., ‘PSDS-PS-C03.a’ (adherence to SP 800-53r5, Sec. 3.10). Finally, bulleted lists are sometimes used as part of a specific guideline when there is no need to address each list item individually.
802
4.1. Data Storage Governance (DSGV)
803
4.1.1. Policy and Planning (PP)
804 805 806
DSGV-PP-C01 – Comprehensive storage security policy: Create a comprehensive storage security policy, either as a dedicated policy or as part of the organization’s security policy. It should include configuration baselines for storage systems and can be based on:
807
•
Recommendations from this publication and cited sources
808
•
Storage-related security standards internal to the organization
809
•
Relevant vendor/industry security best practices
810 811 812 813
DSGV-PP-C02 – Keep the storage security policy current: The storage security policy should be reviewed and updated periodically (at least annually). The security baseline should be updated with the latest vendor and industry recommendations available for storage systems and/or specific storage devices (at least quarterly).
814 815
DSGV-PP-C03 – Compliance with storage security policy: Periodically and proactively assess storage system configurations to verify compliance with the storage security policy, including:
816 817
(a) Confirming that the actual configuration meets the storage security baselines and identifying gaps
818
(b) Tracking the remediation of gaps in a timely manner
819 820
(c) Developing key performance indicators (KPIs) to track compliance with storage security baselines based on types of data, their organization function, and their sensitivity
20
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
821 822
Security Guidelines for Storage Infrastructure
DSGV-PP-C04 – Data protection plan or policy: A data protection plan or policy should be established prior to deployment and should include, at the minimum, the following:
823 824 825
(a) Tiering, frequency, and number of copies to meet the organization’s recovery goals. Specification may include more than one tier (e.g., continuous, hourly, daily, weekly) and should include for each tier:
826
o Frequency and retention (e.g., 48 hourly snapshots, 30 daily backups)
827
o Type (e.g., full, incremental, continuous, replication, point-in-time copies)
828
(b) Types of media to be used
829 830
(c) Encryption capabilities for data at rest and in transit as well as encryption key retention and rotation
831 832 833 834
(d) Other protection capabilities, such as digital signing, location, facility security (including fire, explosion, and magnetic interference protection), immutability and locking, minimum number of copies per backup set, and the geographic distribution of such copies
835
(e) References to applicable regulatory frameworks with appropriate controls
836 837 838
(f) Comprehensive life cycle management, including tracking data copies and backups against protection and retention policies (e.g., affirmative deletion of those that are no longer needed)
839
(g) Restoration procedures
840 841
DSGV-PP-C05 – Completeness of data protection plan or policy: The data protection plan or policy should be comprehensive enough to:
842 843 844 845 846
(a) Cover all data assets of the enterprise, irrespective of where they reside (i.e., onpremises, off-premises or in the cloud). It is acceptable to refrain from protecting data assets that have no significance to the organization or that can be recreated from other protected data sources within the desired RTO, but such omissions should be documented.
847
(b) Be organized by the type of data involved (e.g., Tier 1, Tier 2).
848 849 850
(c) Address data integrity at the application and business process levels (e.g., if two components should be recovered to the same point in time to function properly, then federated consistency mechanisms or equivalent should be planned and implemented).
851 852 853
(d) Address the desired restoration speed to meet business or regulatory obligations so that implementation is based on technology stacks with appropriate characteristics (e.g., disk-based, point-in-time copies versus tape or over-WAN recovery).
854 855
DSGV-PP-C06 – Backup plan or policy: In addition to a backup plan or policy, standard operating procedures related to the backup should:
856 857
(a) Monitor the execution of backups based on policy and associated notification mechanisms.
21
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
858 859 860 861
(b) Periodically test backups (at least monthly for critical data) to verify their integrity and their ability to be restored. For applications with a strict RTO, an end-to-end test restore should be performed (e.g., a complete recovery of the dataset to a sandbox recovery environment, simulating real-life restoration scenarios).
862 863 864 865 866
(c) An up-to-date recovery catalog should be kept to track each copy (e.g., backup, replication, point-in-time copies) and record which anti-malware tools were used and the results of the scans. For sensitive data, it is further recommended to periodically scan at least a subset of past copies with current anti-malware tools to identify “poisoned” copies. See additional cataloging recommendations in DSGV-SR-C02.
867
(d) Periodically review (at least annually) the backup plan and operations procedures.
868 869
(e) Maintain an audit trail that provides the information necessary to determine conformance of the backup operations consistent with the policy.
870 871
(f) Employ special controls when necessary (e.g., refreshing old, at risk, or no longer supported media by copying to new ones).
872 873 874 875 876
DSGV-PP-C07 – Ensure the completeness of recovery copies: All storage elements that contain components of critical data assets should be protected and backed up to support both DR and cyber-attack recovery. This includes storage volumes, critical file systems, databases, software images, certificates, encryption keys, startup files, catalog info, ACLs, virtualization settings, and configuration files.
877 878 879 880
DSGV-PP-C08 – Protect all dependent ICT components: Dependent components (e.g., directory services, DNS, external key management systems) should be protected to enable full recovery. If automated build processes are used to configure storage, then source-code repositories, build-environment, and build-procedures should be protected as well.
881 882 883
DSGV-PP-C09 – Document the DR plan, resources, mapping to production, flow, and test procedures: A disaster recovery plan for storage infrastructure should be written, which includes all of the resources, mapping to production, flows, and test procedures.
884 885
DSGV-PP-C10 – Storage consideration for policy: Storage should be incorporated into policies in order to:
886 887
•
Identify the most sensitive (e.g., PII, intellectual property, trade secrets) and business/mission-critical data categories as well as protection requirements
888 889
•
Integrate storage-specific policies with other policies (i.e., avoid creating a separate policy document for the storage ecosystem)
890
•
Address data retention and protection (e.g., WORM, authenticity, access controls)
891
•
Address storage media sanitization
892
•
Address the role of storage in business continuity management and disaster recovery
893
•
Unique staffing and facility requirements associated with the storage ecosystem
22
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
894 895
Security Guidelines for Storage Infrastructure
DSGV-PP-C11 – Include storage infrastructure in the logging and monitoring policy: Include storage in the logging and monitoring policy such that the policy:
896
•
Clearly states that storage systems and devices participate in audit logging
897
•
Identifies the significant storage-related events to be collected
898
•
Identifies the preservation requirements for storage-related event logs
899
•
Identifies the retention requirements for storage-related event logs
900
•
Specifies the time synchronization and use requirement for storage-related event logs
901
•
Includes evidentiary expectations (e.g., authenticity, chain of custody)
902
•
Establishes expectations for monitoring and alerting
903
4.1.2. Documentation and Testing (DT)
904 905 906 907
DSGV-DT-C01 – Include storage in BCM planning/testing: Organizations should perform ongoing planning and regular testing of storage-oriented assumptions/dependencies, which are critical to a successful BCM. The results of BCM testing should be fed back into ongoing maintenance of the BCM plan.
908 909 910
DSGV-DT-C02 – Document data retention and sanitization obligations: Organizations should document and confirm that storage infrastructure complies with data retention and storage sanitization obligations, including the implementation of:
911
•
Appropriate data retention measures
912
•
Appropriate data integrity and authenticity measures
913
•
Storage sanitization prior to the repurposing or decommissioning of hardware
914
•
Storage sanitization of virtual server images and their copies at their end of life
915 916
DSGV-DT-C03 – Document and verify storage compliance with privacy obligations: Organizations should document and verify that storage meets privacy obligations such that:
917 918
•
Appropriate data access control based on least privilege is implemented to control access to data and metadata (e.g., search results)
919 920
•
Appropriate data confidentiality measures are implemented to prevent unauthorized disclosure
921 922 923
DSGV-DT-C04 – Document and verify storage compliance with legal obligations: Organizations should document and verify that storage infrastructure complies with legal obligations, including:
924
•
Use of data deduplication does not conflict with data authenticity requirements
925 926
•
Data and storage media sanitization mechanisms do not violate preservation requirements
23
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
927 928
•
Security Guidelines for Storage Infrastructure
Proper chain-of-custody procedures are followed when evidentiary data (e.g., audit logs, metadata, mirror images, point-in time copies) is handled
929
4.1.3. Storage Resource Management (SR)
930 931 932
The purpose of configuration management is to provide visibility and control over settings, behavior, and the physical and logical attributes of storage assets throughout their life cycle. In the context of storage security, this involves:
933
•
Maintaining a comprehensive and current inventory
934
•
Managing change
935 936
•
Ensuring that the configuration continually meets the organization’s security baselines and current industry best practices and that it is free of known risks
937 938 939
To this end, appropriate controls, policies, processes, and tools are needed. Comprehensive guidance for IT configuration management is provided in SP 800-53r5 [10]. The following paragraphs provide recommendations that are applicable to storage infrastructure.
940 941 942
DSGV-SR-C01 – Create a comprehensive inventory of all storage devices: This includes identifying the name, address, location, and software, firmware, or driver versions for all storage components, including:
943
•
Arrays
944
•
Storage virtualization systems
945
•
Management consoles
946
•
Hosts used to monitor remote network connectivity statuses (e.g., witness hosts)
947
•
Hosts installed with storage management software or plugins
948
•
Data protection appliances
949
•
Backup clients and servers
950
•
Storage network switches
951
•
Storage adapters or host bus adapters (HBAs)
952
•
I/O multipathing software
953
•
Pairing of primary and replication destination storage systems
954
•
Designated backup servers for hosts or off-site backup
955
•
Tape libraries and drives
956
•
Disk drives and removable media
24
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
957 958 959
Security Guidelines for Storage Infrastructure
DSGV-SR-C02 – Create a comprehensive inventory of all data and configuration assets: This includes identifying logical data components and data access configurations through the following assets:
960
•
Storage pools, LUNs, masking, and zoning
961
•
Initiators and initiator groups
962
•
File shares and ACLs
963
•
Object storage pools and buckets
964
•
Replicas and snapshots
965
•
Backup catalog and access rights
966
•
Backup sets (e.g., on-premises, virtualized in the cloud, on tapes)
967
•
Users, groups, roles, and rights
968 969
•
Host access configuration to storage assets (e.g., LUNs, file shares, global file systems, object storage)
970
•
Images of storage software and virtual appliances
971 972
DSGV-SR-C03 – Network topology documentation: Maintain current storage-related network documentation, including topology drawings (FC and IP).
973 974 975
DSGV-SR-C04 – Detect unauthorized storage security changes: There should be a process for detecting unauthorized changes to storage configuration using logging, comparison of configuration storage assets to past states, or comparison to organization approved baselines.
976 977 978
DSGV-SR-C05 – Develop a response plan for storage component compromise: The following elements in organizational risk analysis, isolation, remediation, restoration, and testing procedures should be addressed:
979 980
(a) Compromise of an entire storage array or cloud-based storage asset (e.g., SAN, NAS, object store, elastic file system)
981
(b) Compromise of a backup system
982
(c) Compromise of an individual storage element (e.g., share, block device)
983
(d) Compromise of an FC SAN fabric, including individual switches and SAN services
984 985 986
DSGV-SR-C06 – Develop a change management process for storage: Create a storage change management process as a dedicated process or as part of the organization’s general change management process. It should cover:
987
(a) Planning, reviewing, and approving storage configuration changes
988 989
(b) Updating environment documentation and inventory (e.g., infrastructure, data, configuration)
990 991
(c) Assessing compliance with relevant security baselines following any change to the sensitive storage environment 25
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
992 993 994 995 996
DSGV-SR-C07 – Perform periodic isolation reviews: Isolation recommendations (see Sec. 4.2.3) should be checked at least once per year as part of a periodic audit to determine whether there are configuration gaps or drifts that could compromise the isolation of the cyber-attack recovery copy. Sensitive and high-value storage systems should be audited at least quarterly and after every major change, whichever comes first. Audit results should be documented.
997 998 999 1000 1001 1002
DSGV-SR-C08 – Set RPO and RTO: Set an RPO for each data asset, which is the amount of data that can be lost following a failure, expressed in time (i.e., measures backward from the moment of the disruption). Likewise, set an RTO for each data asset, which is the amount of downtime that can be tolerated before systems are expected to be restored and functional. The design and implementation of data protection solutions should support data recovery while meeting these objectives.
1003 1004 1005 1006
DSGV-SR-C09 – Meeting organizational frequency and retention objectives: The data retention and copy frequency objectives for each data asset (see DSGV-PP-C06 for more details) should be set. The design and implementation of the backup and data copy technologies should support these objectives.
1007
4.1.4. People Controls (PC)
1008 1009 1010
DSGV-PC-C01 – Storage security training: A storage security training program should be defined and incorporated into existing organizational training activities and schedules to accommodate the following audiences:
1011 1012
•
Information security professionals: To provide them with a fundamental background of storage security
1013 1014
•
Storage administrators: To familiarize them with storage security principles, organization policies, and security baselines
1015
•
Managers: To help them understand the fundamentals of data protection
1016 1017 1018 1019
DSGV-PC-C02 – Ensuring adequate storage data protection expertise: Storage teams and management should understand the technologies and practices associated with storage-based data protection technologies (e.g., backups, replications), including the applicability of data protection in the organization.
1020 1021 1022
DSGV-PC-C03 – Ensuring adequate storage security expertise: Storage teams and management should understand the technologies and practices for securing storage devices, systems, and ecosystems as well as leveraging storage-based security controls.
1023
4.2. Physical Controls for Data Storage (PSDS)
1024 1025 1026 1027 1028
Physical security is fundamental to the overall safeguarding of any IT infrastructure. Most software-based security controls can be compromised if an adversary gains access to the physical facility and equipment. In many regards, physical security for storage infrastructure is identical to those of other infrastructure elements, like computers and network equipment (e.g., facility security, surveillance, transportation). These are addressed in multiple 26
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1029 1030
publications, including SP 800-53r5 [10] and SP 800-171 [13]. Additional valuable discussion regarding media disposal and destruction is available in ISO 27040 [6] SP 800-88r2 [11].
1031 1032
This section provides focused guidance on physical security aspects that are unique to storage infrastructure or are less emphasized in other publications.
1033
4.2.1. Physically Secure Storage (PS)
1034 1035 1036 1037
PSDS-PS-C01 – Physically securing storage media: All storage media with recorded data should be stored in a safe, secure environment according to their information classifications, protections against environmental threats (e.g., heat, moisture, humidity, electronic field, aging), manufacturer specifications.
1038 1039
PSDS-PS-C02 – Physically securing storage devices: Depending on their size and location, storage devices should be physically secured as follows:
1040 1041
•
Small-size units in an office environment can be tethered to furniture or walls or stored in locked cabinet or safes when not in use.
1042 1043
•
Large-size units can be rack-mounted and resident in laboratory or data centers, where they benefit from the security measures of the facility (e.g., locking covers, cages).
1044
PSDS-PS-C03 – Use media security measures:
1045 1046 1047
(a) Follow general recommendations in SP 800-53r5, Sec. 3.10, including policies, access, marking, storage, transport, sanitization, cryptography, removable media, confidentiality, and disposal.
1048 1049
(b) Life cycle management should include purchasing media with adequate supply chain protection.
1050 1051
(c) For sensitive data, physical media for backup should be stored in a location that is sufficiently distant from that in which the primary data is stored.
1052 1053 1054 1055
(d) For sensitive data, a comprehensive inventory of storage media (i.e., cataloging) should be kept to track its location, ownership, capacity, and other relevant configuration attributes. Particular attention should be paid to tracking the actual content of media, including:
1056
•
Sensitivity level
1057 1058
•
Classification (e.g., what type of data it stores, what applications and business services it relates to)
1059
•
Encryption level
1060 1061
•
Potential impact if compromised or stolen (e.g., compromise of financial or medical information; leakage of passwords, certificates, or encryption keys)
1062 1063
•
Mitigation/contingency steps or procedures to employ (e.g., changing passwords, reissuing keys, re-encrypting data, notifying relevant stakeholders)
27
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
1064
•
Security Guidelines for Storage Infrastructure
Dependencies between the data and other applications
1065 1066 1067
(e) Consider using advanced tracking controls on sensitive removable media, such as radiofrequency identification (RFID) tags, Global Positioning System (GPS) tracking devices, and tamper protection.
1068 1069 1070 1071
(f) For extremely sensitive information, consider using self-activated and/or remotely controlled self-destruction mechanisms. When implemented, carefully address how to protect such capabilities as they present an attack vector that an adversary can use to trigger destruction of the devices or to harm nearby equipment, data, and personnel.
1072 1073 1074 1075 1076 1077 1078
PSDS-PS-C04 – Protect all sensitive administrative equipment: Sensitive workstations, which can be used to obtain administrative access to storage infrastructure, should be managed using organization-approved security controls for access, surveillance, and auditing, including physical security. The security measures taken to protect the management workstations should be at least as strict as those used to protect the data it manages and the systems that use that data. This includes workstations located outside of the facility storing the data and work-from-home environments, when used.
1079 1080 1081 1082 1083 1084 1085 1086 1087
PSDS-PS-C05 – Use of storage sanitization: The sanitization approach should cover storage infrastructure in detail, including non-obvious storage components. Certain elements capable of storing sensitive data beyond the media itself are sometimes overlooked when disposing of storage equipment (see Sec. 4.7), including non-volatile memory and cache objects (often found in storage arrays, SAN switches, and routers), firmware/BIOS settings, and HBA-level settings that can contain organizationally identifiable addresses (e.g., IP and SAN Fabric World Wide Names [WWNs], masking configuration, passwords). Validate that all of those elements are considered as part of the organization data sanitization policy, including policy definition, operations, and audits.
1088 1089 1090
PSDS-PS-C06 – Use of immutable storage: If possible and appropriate, immutable storage should be used to help further isolate and protect recovery data (e.g., retention locking, vault locking, immutability policies).
1091
4.2.2. Protect Physical Interfaces (PI)
1092 1093
PSDS-PI-C01 – Protect physical management interfaces to storage: To protect the management of physical interfaces, the organization should:
1094
•
Restrict physical access to management interfaces
1095
•
Disable and disconnect serial management ports when not in use
1096 1097
•
Segregate LAN interfaces used for management from other LAN traffic, noting that physical isolation is preferred but logical isolation (e.g., VLANs) is acceptable
1098
•
Disable modem ports when not needed
1099 1100
PSDS-PI-C02 – Protect physical SAN interfaces: Limit which SAN Fibre Channel physical and logical ports can be used for in-band management on all SAN switches and storage arrays.
28
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1101
4.2.3. Isolation of Storage Systems (IS)
1102 1103 1104 1105 1106 1107
When production data is damaged or lost, organizations should be able to recover it using replicated or backed up data copies. If the damage is the result of a malicious attack, and the adversaries were also able to compromise the backup data copies, the attack on the production environment can have a devastating effect since the organization will not have the ability to recover. To improve the resilience of backup copies, sufficient isolation should be guaranteed between data assets and their recovery copies.
1108 1109
In this context, organizations should distinguish between at least two separate data protection scenarios:
1110 1111 1112 1113 1114
•
Non-malicious recovery: Having data copies that can be used in the event of a natural disaster, hardware failure, human error, or other event. These can include local copies (e.g., snapshots taken before performing maintenance), DR copies, backups, and off-site copies. The “closer” the copy is to the production environment, the more likely it is to be mapped to compute systems for the purpose of testing and DR.
1115 1116 1117 1118
•
Cyber-attack recovery: Having data copes that are hardened, locked, and kept in isolation. The design should strive to achieve a state in which these copies cannot be impacted by anything, including scenarios wherein production volumes or other types of link copies have been compromised.
1119 1120 1121 1122 1123 1124 1125 1126
Keeping copies for cyber-attack recovery that are completely separate from those used for nonmalicious recovery is recommended for critical and sensitive systems but not mandatory. It is important, however, that the data protection scheme in use is suitable to fully support the two scenarios. If existing copy retention mechanisms (e.g., DR or BC copies, off-site copies) are intended to support cyber-attack recovery, their configuration should be reviewed and adjusted to facilitate data isolation. This includes verification that at least a subset of those recovery copies and systems are inaccessible and independent from the production environment and that a compromise of production would not allow adversaries to impact those copies.
1127 1128
The following security recommendations apply to the creation and management of data copies and the associated management system.
1129 1130 1131 1132
PSDS-IS-C01 – Separation of storage systems: Organizations should distinguish between at least two separate data protection scenarios: non-malicious recovery and cyber-attack recovery. The following security recommendations apply to the creation and management of data copies:
1133 1134 1135
(a) Cyber-attack recovery copies should be created on designated, separated storage environments. In private clouds, this implies physically separated storage systems. In public clouds, this implies separate accounts (or equivalent).
1136
(b) Backup systems should be separated from production data storage systems.
1137 1138 1139
PSDS-IS-C02 – Separation of management systems: Storage systems that store cyber-attack recovery copies should be managed from designated management systems that are separated from the production environment and any other system connected to production (e.g., data
29
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1140 1141 1142
protection mechanisms). It should not be possible to access such management systems with regular credentials, including production and regular backups. The system should be hosted on a dedicated environment that is only connected to an isolated network.
1143
PCDS-IS-C03 – Isolation of storage systems: Physical isolation should be used to:
1144 1145
•
Segregate production from other system classes (e.g., quality assurance, development), including:
1146 1147
o Avoiding network connections between classes (e.g., a production server connected to both the production and development networks), when possible
1148
o Segregating networks and storage by class, when appropriate
1149
o Physically separating systems in each class
1150 1151 1152
•
Isolate storage devices from other data center devices, if practical
PCDS-IS-C04 – Logically isolating storage systems: Logical isolation should be used to: •
Segregate storage traffic from normal server traffic using:
1153 1154
o Available network controls to create independent logical domains on common physical infrastructure
1155
o Trust and access controls to manage membership in the logical domains
1156
•
Segregate storage management traffic from all other traffic
1157
•
Configure network gateways for appropriate network segregation
1158
4.3. Storage Systems Security (DSSS)
1159 1160
DSSS-GN-C01 – Defense in depth for storage: A storage systems and solutions defense-indepth approach [25] should:
1161 1162
•
Have a balanced focus on the three primary elements: people, technology, and operations
1163 1164 1165
•
Establish effective information assurance policies and procedures, the assignment of roles and responsibilities, the commitment of resources, the training of critical personnel, and personal accountability
1166
•
Deploy protection mechanisms at multiple locations to resist multiple classes of attacks
1167 1168
•
Deploy multiple layers of defense mechanisms between potential adversaries and targets
1169
•
Include both detective and protective mechanisms
1170 1171 1172
•
Leverage robust (e.g., support many use cases and volumes) and highly attack-resistant (e.g., zero trust architectures) security infrastructures (e.g., key management, public-key infrastructure, identity management) that are centrally managed and monitored
30
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1173
•
Maintain visible and up-to-date system security policies
1174 1175
•
Actively manage the security posture of the storage technology and protection mechanisms (e.g., install security patches, antivirus updates, maintain ACLs)
1176
•
Perform regular security threat assessments to evaluate security readiness
1177
•
Monitor and react to current threats
1178 1179
DSSS-GN-C02 – Establish security domains for storage: Data sensitivity should be factored into the design of security domains [25] such that:
1180 1181
•
Storage and storage networks of different sensitivity levels should be located in different security domains.
1182 1183 1184
•
Devices and computer systems that provide services for external networks (e.g., the internet) should be located in different domains (i.e., demilitarized zone) than internal network devices and computer systems.
1185
•
Strategic assets should be located in dedicated security domains.
1186 1187
•
Untrusted devices and computer systems should have limited or no access to storage assets.
1188 1189
DSSS-GN-C03 – Align storage security domains with purpose: Purpose should be factored into the design of security domains such that:
1190 1191 1192
•
Storage and storage networks used for different purposes (e.g., development, production, management) and using different technologies (e.g., SMB, NFS, iSCSI, CDMI) should be located in separate security domains.
1193 1194 1195
•
Storage networks should be in different security domains than regular networks using the same technology (e.g., the IP networks carrying iSCSI traffic should be segregated from general-purpose LANs).
1196 1197
•
Storage device and storage network management systems should be located in dedicated security domains.
1198
•
Development systems should be in different domains than production systems.
1199
4.3.1. Storage Systems Hardening (SH)
1200 1201
DSSS-SH-C01 – Perform basic operating system hardening: As part of the security hygiene of storage systems, organizations should:
1202
•
Remove unneeded/unused software, services, and protocols
1203
•
Remove unnecessary accounts
1204 1205
•
Rename or disable predefined or default accounts when possible and change all default passwords
1206
•
Only open network ports that are needed
31
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1207
•
Install the latest patches from a trusted source
1208
•
Update firmware from a trusted source
1209
•
Install and maintain malware protections
1210
•
Apply vendor-recommend security configurations
1211 1212 1213 1214 1215
DSSS-SH-C02 – Use software updates and patches from trusted sources: When elements of the storage infrastructure receive an update (e.g., firmware) or patch, there should be some assurance that the software to be applied is from a trusted source. Otherwise, adversaries can write their own update malicious code of their choosing, such as a rootkit, botnet, or other malware.
1216 1217 1218
DSSS-SH-C03 – Limit network access to management ports of SAN switches: Network access to the management ports of SAN switches should be limited to devices and administrators specifically assigned to manage the switches through a mechanism, such as an ACL.
1219 1220 1221 1222
DSSS-SH-C04 – Limit storage administrative capabilities: Control and limit the devices and components that have administrative capabilities to the minimum necessary. This includes CLI servers, management consoles, API gateways, witness hosts, and storage devices with control permissions. In particular:
1223 1224 1225
(a) Actively discover components that have storage administration capabilities and verify that only the components that are authorized have them. Remove unnecessary ones, if found, and debrief.
1226
(b) Remove unnecessary rights and capabilities from authorized devices.
1227 1228 1229 1230
DSSS-SH-C05 – Favor API access control over CLI/shell access: API access, if available, should be used instead of CLI/shell access because of the latter’s ability to access the underlying OS and file systems, including configuration files. If CLI is the only option available, then it should be used over secure protocols (e.g., SSH), as stated in DSSS-SH-C23.
1231 1232 1233
DSSS-SH-C06 – Restrict management console OS privileges: Access to management consoles should only be provided through designated storage accounts and not as an OS administrative account (see DSSS-AM-C14).
1234 1235 1236
DSSS-SH-C07 – Manage web user interfaces: The web service providing access to management consoles should be hardened to meet or exceed the minimum standards of other webapplication servers in the organization.
1237 1238
DSSS-SH-C08 – Secure storage management interfaces: Storage management software/firmware interfaces should be secured with the following:
1239 1240
•
Firewalls and network ACLs to restrict access to management networks to authorized systems and protocols
1241 1242
•
Entity authentication to establish trust relationships between storage systems and the management systems (e.g., authenticate the entities performing in-band management)
32
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1243 1244
•
Intrusion detection system and intrusion prevention system mechanisms to identify anomalous behaviors and guard against them
1245 1246
•
ICT infrastructure (e.g., DNS, Service Location Protocol [SLP], Network Time Protocol [NTP]) with appropriate security controls to avoid indirect attacks
1247 1248
•
Appropriate privileged user controls, including authentication, authorization, and secure auditing/monitoring
1249 1250
•
Up-to-date operating systems and applications that are sufficiently hardened against attacks
1251 1252
DSSS-SH-C09 – Secure the remote management: When storage systems are managed remotely, the following additional security measures should be used:
1253
•
Secure channels for all remote access, such as VPNs, TLS, Secure Shell (SSH), or HTTPS
1254
•
Strong authentication or multi-factor authentication
1255
•
Restricted privileges to the minimum necessary (i.e., least privilege)
1256 1257 1258 1259 1260
DSSS-SH-C10 – Restrict vendor maintenance interfaces: The organization should devise organizational and technical controls to restrict the management interface used for remote (i.e., non-local) vendor maintenance sessions. Remote vendor maintenance operations conducted by individuals communicating through an external network (e.g., the internet) impose significant risks to availability, integrity, and confidentiality.
1261 1262 1263 1264 1265 1266
DSSS-SH-C11 – Restrict vendor maintenance communications: Technical controls should restrict communication traffic (i.e., systems, ports, and protocols) to the minimum required for remote vendor maintenance operations. After the accessing party is authenticated, additional controls at the access point should be devised to authorize the vendor maintenance session. These include accepting, asking for approval, or denying the requested session. Appropriate logs containing audit records of vendor actions should be generated.
1267 1268 1269 1270
DSSS-SH-C12 – Restrict vendor dial-up maintenance: The organization should restrict dial-up access lines to authorized accessing parties. This includes enforcing a modem call-back protocol and disabling connection establishment until the vendor requests a maintenance session and the request is authorized by the organization.
1271 1272
DSSS-SH-C13 – Secure Intelligent Platform Management Interface (IPMI): When IPMI is used, the following additional security measures are necessary:
1273 1274
•
IPMI should be disabled as the default configuration setting and only be enabled on a temporary basis when needed.
1275 1276
•
IPMI traffic (usually UDP port 623) should be restricted to trusted internal networks, such as a management VLAN segment with strong network controls.
1277 1278
•
Strong, unique passwords should be set and used for the IPMI service on devices running IPMI.
1279
•
Encryption should be enabled on IPMI (e.g., with RMCP or RMCP+ protocols), if possible.
33
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1280 1281 1282
•
“Cipher 0” (enabled by default on many IPMI enabled devices) and anonymous logins should be disabled to prevent adversaries from bypassing authentication and sending arbitrary IPMI commands.
1283
•
Stored passwords should be sanitized at the system’s end of life (see PSDS-PS-C05).
1284 1285 1286 1287 1288
DSSS-SH-C14 – Restrict host storage control privileges: In certain shared data compute cluster configurations (e.g., clusters, geo-clusters, scale-sets, storage virtualization infrastructure), hosts are granted administrative access to storage in order to control shared cluster data resource allocation and behavior. When such administrative access is necessary, restrict the scope and privileges granted to hosts to:
1289 1290
(a) Only the particular elements (e.g., LUNs, shares, files, objects) that the hosts need to control
1291
(b) Only the specific actions that the hosts need to perform.
1292 1293 1294 1295 1296
DSSS-SH-C15 – Command device or gatekeeper configuration: Certain storage arrays allow inband administrative control to hosts with access to special block devices (e.g., devices referred to by certain vendors as “command device” and ”gatekeeper”). Commands are transferred using I/O operations on those special devices. When used, the following security guidelines are recommended:
1297 1298 1299
(a) Limit the use of control devices to the minimum possible: If feasible, eliminate the use of such devices completely (e.g., using API access instead). If not, map them to specific approved hosts only (e.g., management hosts).
1300 1301
(b) Scan for control devices – Perform network scanning to discover control devices, and confirm that they are mapped to the authorized hosts only.
1302 1303 1304 1305 1306 1307 1308 1309
DSSS-SH-C16 – Disable or limit call home or remote access: Storage infrastructure systems can have the ability to send certain telemetry and diagnostic data back to the manufacturer, such as logs. In some cases, they even enable remote connection to the system by the manufacturer with administrative rights. These mechanisms are in place to allow the manufacturer to investigate and resolve technical issues and to perform automated software updates. These capabilities can potentially be exploited by adversaries and should be disabled if they are not used. However, if they are used, they should be limited and controlled by implementing the following settings:
1310 1311
(a) Change the default credentials: Modify the default credentials used for the remote connection.
1312
(b) Limit permissions: Limit access permissions to only the minimal level needed.
1313 1314
(c) Enforce encryption: Secure protocols (e.g., TLS/SSH/IPSEC using FIPS-approved encryption algorithms) should be used.
1315 1316
(d) Limit access with an “allow list”: Utilize an allow list that limits access by specific IPs and specific users.
1317
(e) Log remote access: All remote access should be fully logged for auditing purposes.
34
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1318 1319 1320
(f) Enable built-in data obfuscation features: This is applicable for storage devices that allow the obfuscation of sensitive data, such as IP addresses, WWNs, device names, and usernames.
1321
(g) Limit the scope of data sent to the minimum necessary.
1322 1323 1324 1325
(h) Review and approve: Periodically evaluate the data that is occasionally or automatically being sent to the vendor to confirm that it does not contain sensitive information, such as IP addresses, usernames, or the actual content of storage devices. Review that the connection is performed to valid vendor IP addresses.
1326 1327
(i) Authorize each connection: If possible, implement a mechanism that will ask permission before allowing each connection.
1328 1329 1330
(j) Restrict access to gateway system: When remote access by the vendor is performed through a gateway device, server, or appliance, take particular care to secure and restrict access to the gateway system.
1331 1332 1333
(k) Disable software updates over vendor remote access links: In sensitive environments, downloading and deploying software components and updates (manual or automated) should not be allowed through remote vendor connection links.
1334 1335 1336
DSSS-SH-C17 – Access control for management networks: In addition to separating management from other traffic in sensitive environments, further access control for management networks is recommended using mechanisms such as:
1337 1338 1339 1340
(a) VPNs, IPsec, or one or more “jump servers” or “login proxies,” which are dedicated servers in the management network that are the only ones accessible from outside of the management network and can serve to connect to other servers after proper authentication and authorization
1341
(b) Enhanced logging and tracing, such as session recording
1342 1343 1344 1345 1346
DSSS-SH-C18 – Secure and protect core storage management files and binaries: Storage management software often includes configuration files that present various options to control how the storage system would operate, including undocumented options. Such sensitive directories and files should be kept with appropriate limited permission, ownership, and group membership. This includes:
1347 1348 1349 1350 1351
•
Configuration files: Outlining users, roles, network settings, consistency groups, device groups, and other storage options. The configuration files that define consistency and device groups are often automatically propagated from central management hosts to other hosts that are attached to the managed storage system. Thus, if compromised, it can affect multiple systems.
1352 1353
•
Scripts: Storage management services, daemons, and the binaries themselves should be kept in a secure way to control starting, monitoring, and stopping.
35
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1354 1355
The following controls should be applied to configuration files, scripts, and any other important management-related files:
1356
(a) Restrict access and permissions, and control the ownership of key folders and files.
1357 1358
(b) For sensitive environments, monitor for content changes in such files to prevent unauthorized changes or additions.
1359 1360 1361
DSSS-SH-C19 – Use an approved PKI mechanism for management access: Use an organizationapproved and certified centralized PKI system for storage device management and storage management consoles rather than device or software self-signed certificates.
1362 1363 1364
DSSS-SH-C20 – Perform regular security audits of data: Regular audits of the security settings for storage data of all types (e.g., files, objects) should be performed to determine whether there are drifts. Audit results should be documented.
1365 1366 1367 1368 1369 1370
DSSS-SH-C21 – Disallow cleartext protocols: Cleartext protocols (e.g., HTTP, Telnet, File Transfer Protocol [FTP], remote shell [RSH]) should not be used. Cleartext protocols are vulnerable to sniffing, interception, and other attacks as they do not encrypt traffic or logon details, making it easy for an eavesdropper to intercept this data. In some implementations, HTTP is only supported for redirecting to HTTPS to address mistyped URLs. This should not be allowed in sensitive storage environments.
1371 1372 1373 1374
DSSS-SH-C22 – Encryption for storage management API sessions: Storage management APIs and CLIs are used for administrative access to storage systems. All API and CLI client sessions should be encrypted, leveraging features such as vendor configuration options within the management software or the API/CLI software component.
1375 1376 1377 1378
DSSS-SH-C23 – Encryption for administrative access sessions: Administrative sessions over HTTP should use TLS (HTTPS). CLI access should be encrypted using SSH rather than Telnet. The authentication during API access should not use cleartext, and the session itself should be encrypted.
1379 1380 1381 1382 1383 1384
DSSS-SH-C24 – Enable FIPS mode for FIPS-based environments: FIPS 140-3 [32] specifies that a cryptographic module should be a set of hardware, software, firmware, or some combination of those that implements cryptographic functions or processes, including cryptographic algorithms and key generation, and is contained within a defined cryptographic boundary. The cryptographic modules used in storage infrastructure to protect sensitive data should be FIPS 140-3-validated, and the FIPS mode should be enabled.
1385
4.3.2. Security Auditing and Monitoring (SA)
1386 1387 1388 1389 1390
Storage infrastructure components generate event log entries for a wide range of transactions or events. From a security or compliance perspective, it is important to capture event log entries that are necessary to demonstrate proof of operations (e.g., encryption, retention), the enforcement of accountability and traceability, meeting evidentiary obligations, and adequate monitoring of systems. This subset of general event logging is commonly called audit logging.
36
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
1391
Security Guidelines for Storage Infrastructure
The following audit logging events are relevant for security purposes:
1392 1393 1394
•
Management events, such as resetting user passwords, account creation/deletion, modification of privileges, role changes, group membership changes, privileged actions, and creating or changing configuration. These events are always of interest.
1395 1396 1397
•
Security-related events, such as changes to user profiles and security configurations, failed/blocked attempts to storage, and blocked logins. These events are most often of interest, though some of them may overlap with management events.
1398 1399 1400
•
Data access events, such as access information. These events are of interest for incident response in monitoring sensitive information (e.g., determining what an adversary has touched).
1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413
Deficiencies in security logging and analysis allow adversaries to hide their location, malicious software, and activities on victims’ machines. Even if the victims know that their systems have been compromised, without protected and complete logging records, they are blind to the details of the attack and to subsequent actions taken by the adversaries. Without adequate audit logs, an attack can go unnoticed indefinitely, and the actual damage done may be irreversible. Sometimes, logging records are the only evidence of a successful attack. Many organizations keep audit records for compliance purposes, but adversaries rely on the fact that such organizations rarely look at the audit logs and do not know that their systems have been compromised. Because of poor or nonexistent log analysis processes, adversaries sometimes control victim machines for months or years without anyone in the target organization knowing, even though evidence of the attack can be obtained in unexamined log files. Based on the criticality of event log data for attack detection and forensic investigation, the following are the security recommendations for implementing audit logging capabilities.
1414 1415
DSSS-SA-C01 – Configure and use logging on storage infrastructure: Storage infrastructure should participate in logging such that:
1416
•
Event logging is enabled on storage systems and devices, where possible.
1417
•
External or centralized event logging is used and can use local logging.
1418 1419
•
A common, accurate time source is used across the environment so that event records from different sources can be correlated.
1420 1421
•
Events are natively logged using standard logging protocols (e.g., syslog) that support reliable delivery and secure transports (e.g., TLS), where possible.
1422
•
External or centralized event logging is used with a trusted remote source.
1423 1424 1425 1426
•
Device logs for anything other than system health monitoring and debugging are avoided because device-resident logs are more easily subjected to tampering or destruction, there is limited storage space available for logs (e.g., logs are overwritten), and they preclude the use of centralized automated analysis, alerting, and retention.
1427
•
Multiple, external log servers are used for redundancy.
37
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
1428 1429 1430 1431 1432
•
Security Guidelines for Storage Infrastructure
Events are logged as they occur (i.e., no buffering) when the primary drivers for audit logging are compliance, accountability, or security.
DSSS-SA-C02 – Ensure completeness of storage logging: The usefulness of event logging is somewhat dependent on the information captured (e.g., timestamps, sources, types of events). For storage systems, ensuring the completeness of the audit log entries includes:
1433 1434
•
Once the types of events to be logged have been determined, then all occurrences of these events should be consistently logged, whether in-band or out-of-band.
1435
•
The following kinds of events should be logged (a minimum set of security events):
1436
o Failed and successful logon attempts
1437
o Failed file and object access attempts for sensitive and high-value data
1438
o Account and group profile additions, changes, and deletions
1439 1440
o Changes to system security configurations (e.g., audit logging, network filtering, zoning changes)
1441
o Changes to security server usage (e.g., syslog, NTP, DNS, authentication)
1442
o System shutdown and restart
1443
o Privileged operations (i.e., administrator-initiated changes)
1444
o Use of sensitive utilities (e.g., privilege escalation commands)
1445
o Access to critical data files
1446
o Movement of virtual servers between physical servers
1447
•
Each log entry should include:
1448
o A timestamp (i.e., date and time)
1449
o Severity level
1450
o The source of the log entry (e.g., distinguishing name, IP address)
1451
o An event ID
1452
o Textual description of the event to enable localization/internationalization
1453 1454
DSSS-SA-C03 – Monitor storage infrastructure: Storage infrastructure monitoring should be implemented, including:
1455
•
Careful filtering (e.g., on fields like severity) that complies with the logging policy
1456 1457
•
An analysis protocol to correlate audit log records across event sources to identify significant security events
1458 1459
•
Storage logging in security information and event management (SIEM) solutions, when such technology is deployed
1460 1461
•
Storage systems and devices in the information security continuous monitoring (ISCM) solutions, when such technology is deployed 38
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
1462 1463
Security Guidelines for Storage Infrastructure
DSSS-SA-C04 – Protect and retain storage logs: Implement appropriate log retention and protection such that:
1464 1465
•
Audit log data with evidentiary value is handled correctly (e.g., maintain chain of custody, verifiable integrity and authenticity).
1466 1467
•
Audit log data with specific retention requirements (e.g., for regulatory compliance) should be preserved with the organization’s data retention solution.
1468 1469
•
Appropriate measures are implemented to preserve log integrity and prevent their modification or destruction (either maliciously or accidentally).
1470 1471 1472
•
When audit log entries contain sensitive information, the audit log data should be protected with appropriate confidentiality mechanisms to prevent their becoming another vector for information leakage.
1473 1474
•
Dedicated, hardened, and configured systems should be used for unique audit logging requirements (e.g., high volume, special preservation, event signing).
1475 1476
•
Log relays and log filtering should be leveraged to minimize the impact of specialized storage requirements (e.g., WORM).
1477 1478
DSSS-SA-C05 – Enable audit logging: Audit logging should be enabled on all storage infrastructure components using reliable delivery and secure protocols.
1479 1480 1481 1482 1483 1484 1485 1486
DSSS-SA-C06 – Reliable, external time synchronization: An NTP service is critical for time synchronization across the infrastructure. If the NTP service is disabled, dependent systems can suffer from inaccurate timestamps on messages, events, alerts; inconsistent time across different devices; and the subsequent failure to perform log analysis, correlation, anomaly detection or forensics. Establishing and using a common, accurate time source across the environment can help correlate event records from different sources. The following are recommendations regarding the deployment and integration of NTP with storage-related devices:
1487 1488
(a) The NTP service should be enabled on all devices, including log servers and storage infrastructure.
1489 1490
(b) All devices should be configured to synchronize time with a time source server, such as an NTP server.
1491 1492 1493
(c) Time synchronization validity should be monitored on all devices (e.g., that the service remains activated, that organization-approved time servers are configured in each device), and alerts for detected anomalies should be handled at a high priority.
1494 1495
(d) Redundancy for time source servers should be provided by deploying at least three synchronized time sources that are geographically distributed.
1496
(e) Certificate-based authentication should be used to authenticate the time source server.
1497 1498
(f) Access control options (e.g., “ntpd” access restrictions) should be leveraged to restrict access to the time source servers.
39
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1499 1500 1501 1502
DSSS-SA-C07 – Collect logs in a centralized fashion: Writing logs to central log servers (e.g., syslog server, cloud logging services) secures them within the internal network and lowers the risk of those logs being lost or altered. The following are recommendations regarding the deployment and integration of central logging with storage-related devices:
1503 1504 1505 1506
(a) Organizational logging standards for storage devices should be defined to specify the logging level. Management events and security-related events should be logged for all types of data. For extremely sensitive data, data access events should also be logged (see DSSS-SA-C08).
1507 1508
(b) All devices should be configured to transmit log event data to organization-approved central log servers according to the applicable organizational logging standard.
1509 1510 1511 1512
(c) Central logging configuration validity should be monitored on all devices (e.g., that the logging service remains activated, that logging level configuration matches the organization standards, that organization-approved log servers are configured in each device), and alerts for detected anomalies should be handled at a high priority.
1513 1514
(d) Multiple syslog servers should be deployed to enable continuous logging and prevent a single point of failure.
1515
(e) At least one off-site copy for each log should be maintained.
1516 1517 1518
(f) To prevent the loss of entries if the logging process is stopped and restarted before all entries are written, logging should be configured to be written to disk in real time with no buffers in place and sent over reliable protocols.
1519 1520
DSSS-SA-C08 – Auding logging level: The following events related to the storage protection of all storage-related objects, sites, and accounts should be included in the storage audit logging:
1521
(a) Read-only API calls in sensitive environments
1522
(b) All denied access attempts to services, ports, files, objects, or devices
1523 1524 1525
(c) Cryptographic key management operations spanning the entire key life cycle (e.g., key generation, key deletion, certificate management), especially for events such as key shredding
1526 1527
DSSS-SA-C09 – Audit log retention and protection: The following measures should be adopted for audit log retention and protection:
1528 1529
(a) Retain log data for a sufficiently long period of time, as it often takes a while to notice that a compromise has occurred or is occurring.
1530 1531 1532 1533
(b) Allocate sufficient storage space and proactively monitor free space and unusual growth rates of log data to prevent log destinations from filling up. A known attack pattern involves filling up logs with meaningless entries to disrupt forensics, and appropriate monitoring can help identify such attacks in real time.
1534 1535 1536
(c) Retained log data should be protected from tampering (e.g., using WORM or immutable storage, object locking, MFA approval for delete). If supported, the central log servers should also use such storage options. 40
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1537
(d) Restrict access to log data and servers using designated roles and accounts.
1538 1539
(e) Enable encryption since access to log data can provide adversaries with valuable insight into assets and possible attack vectors.
1540 1541
DSSS-SA-C10 – SIEM integration: If supported, storage infrastructure logs should be integrated with SIEM software for potential threat detection.
1542
4.3.3. Storage Vulnerability Management (VM)
1543 1544 1545 1546 1547 1548
DSSS-VM-C01 – Include storage infrastructure in vulnerability management programs: Due to the specialized nature of storage technologies, storage systems are not always included in an organization’s vulnerability management program. In addition, many of the tools used to identify vulnerabilities do not provide extensive coverage of storage operating systems and applications. Organizations should include storage systems in their vulnerability management programs.
1549
DSSS-VM-C02 – Software updates and patches:
1550 1551 1552 1553
(a) Apply storage software releases: There should be a process for periodically updating storage software to the latest stable and secure storage release available. This includes management software, API and CLI packages, array and HBA firmware versions, and OS drivers.
1554 1555 1556
(b) Apply important security updates and patches: There should be a process to proactively and frequently install important and urgent storage security fixes and patches.
1557 1558 1559
(c) Mitigation plan for missing patches: Storage components with a critical vulnerability for which the vendor has not issued an update or patch should be suspended from use unless an appropriate mitigation plan can be defined and put in place.
1560 1561 1562
DSSS-VM-C03 – Scan files that contain sensitive information with anti-malware tools on access: Every time a file with sensitive information is accessed, it should first be scanned with organization-approved anti-malware tools to determine whether it has been compromised.
1563
4.3.4. Storage Accounting and Management (AM)
1564
4.3.4.1. Authentication Recommendations
1565 1566 1567 1568 1569 1570
DSSS-AM-C01 – Unique identifier for all users: All users (particularly administrators) should have a unique identifier for their personal use. Identifiers assigned to administrators should, at a minimum, meet identity assurance level 3 (IAL 3) (see Sec. 4.2 and 4.5 in SP 800-63A[30]). The only exception is an emergency-use account whose secure usage is outlined in DSSS-AM-C10. This principle is important for accountability, audit purposes, and the ability to control access on the individual user level.
41
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1571 1572 1573 1574 1575 1576 1577
DSSS-AM-C02 – Use centralized authentication solution: In a large-scale environment, a centralized authentication solution (e.g., Active Directory, Lightweight Directory Access Protocol [LDAP], single sign-on [SSO], organization-approved cloud authentication services) should be deployed to enable the close monitoring and control of user access to storage resources as well as the uniform enforcement of the organization’s authentication policies. The use of built-in authentication and permissions management capabilities should be avoided and preferably disabled.
1578
DSSS-AM-C03 – Configuration of authentication servers:
1579 1580 1581
(a) The designation of servers to perform authentication services should be strictly controlled, and their validity should be periodically checked to detect and prevent the introduction of any rogue or unauthorized authentication servers.
1582 1583
(b) There should be multiple authentication servers to ensure availability and avoid single points of failure.
1584 1585 1586
DSSS-AM-C04 – Secure connection to centralized authentication server: All communication between the centralized authentication server and the authenticating clients should be secured through state-of-the-art protocols, such as Transport Layer Security (TLS) 1.2 or higher.
1587 1588 1589 1590 1591
DSSS-AM-C05 – Use of multi-factor authentication: Access configuration to storage infrastructure components that store mission-critical data should be protected using a minimum of two-factor authentication with authenticator capabilities outlined in Sec. 5.1.9 of SP 800-63B [15]. MFA should be used for access by users assigned to Security Administrator and Storage Administrator roles.
1592 1593 1594 1595 1596 1597 1598
DSSS-AM-C06 – Entity authentication: In addition to user authentication, storage systems sometimes employ entity authentication, which is the process by which an agent in a distributed system gains confidence in the identity of a communication partner. This entity authentication can take place in TLS and IPsec connections as well as storage protocols (e.g., Challenge-Handshake Authentication Protocol [CHAP] with iSCSI, Diffie-Hellman ChallengeHandshake Authentication Protocol [DH-CHAP] within FCP). When possible, these entity authentication mechanisms should be used.
1599 1600 1601 1602 1603
DSSS-AM-C07 – Secure password policies should cover service accounts: Secure password policies should be applied to individual accounts, service accounts (e.g., Simple Network Management Protocol [SNMP], Network Data Management Protocol [NDMP]), and accounts used by automation tools. The passwords should comply with Sec. 5.1.1 of SP 800-63B [15] for memorized secrets.
1604
4.3.4.2. Account Management Recommendations
1605 1606 1607 1608 1609
DSSS-AM-C08 – Use of accounts not associated with system users: Accounts not associated with any system user (e.g., not in an active directory, such as “guest,” “anonymous,” “nobody”) should be disabled. If they need to be used, they should not be mapped to any system user, and all of their default configurations (e.g., password, privileges) should be changed to conform to organization-wide policies. 42
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1610 1611 1612 1613 1614
DSSS-AM-C09 – Account lockout: Users should be locked out after a certain number of unsuccessful login attempts to mitigate brute force password guessing attempts. Implementations of account locking include automatic reset (i.e., account unlock) after a specified period of time or a power cycle. Automatic reset should not be allowed on sensitive storage systems.
1615 1616 1617 1618 1619 1620
DSSS-AM-C10 – A local user account for emergency purposes: A single local user account should be maintained for access to storage resources in order to provide emergency-only access if the centralized authentication system is down. This account should conform to all organizational policies (e.g., password length). In addition, its usage should be allowed from a physically protected location and following well-documented procedures that include the appropriate approvals of relevant stakeholders and notifications of use.
1621 1622 1623 1624
DSSS-AM-C11 – Eliminate or disable default user accounts: Any default user accounts that come with the storage system installations should be removed or disabled immediately. If the accounts cannot be disabled or removed, or there is a justified reason to keep any of those accounts, the privileges assigned to those accounts should be kept to the minimum necessary.
1625 1626
DSSS-AM-C12 – Limit local and default user accounts: As much as possible, eliminate the use of local and default accounts. If this is not possible:
1627
(a) Limit the use of such accounts and the privileges they have.
1628 1629
(b) Password policies should apply to all user, local, and default accounts, including those with administrative rights.
1630
4.3.4.3. Privilege and Session Management Recommendations
1631 1632 1633 1634 1635 1636 1637 1638
DSSS-AM-C13 – Roles and responsibilities configuration: At a minimum, the four roles in the ISO Standard ISO/IEC 27040 [6] should be implemented for all access to storage resources (e.g., security administrator, storage administrator, security auditor, storage auditor) (see DSSS-AMC18). Storage products that offer only one or two levels or privileges should not be used for storing sensitive information unless compensating controls are available to provide equivalent functionality of granular roles. For example, all management traffic should be routed through a management proxy host or “command gateway” with privilege management tools installed to restrict commands available to each role.
1639 1640 1641 1642
DSSS-AM-C14 – Separation of duties: A critical aspect of storage security is to separate administrative control planes. For example, if an adversary gains control over a host or compromises a host administrator role, they should not be able to trivially compromise its data assets, backups, and replicas. At a minimum, this includes:
1643 1644 1645
(a) The privileges for data management (e.g., create and map a volume or share) and data protection (e.g., configure, stop, and delete backups) should be assigned to different roles, and these roles should not be assigned to the same user.
43
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1646 1647 1648
(b) The privileges for data management and host administration (e.g., creating/deleting objects in the storage controller) should be assigned to different roles, and these roles should not be assigned to the same user.
1649 1650 1651 1652
DSSS-AM-C15 – The privileges assigned to any role should adhere to the principle of least privilege: The permissions assigned to a role should be no more than what is necessary to perform the functions designated for that role [25], such as access to storage-specific resources (e.g., block-devices, files, objects).
1653 1654 1655
DSSS-AM-C16 – Secure session management: All sessions between the client and a storage infrastructure system should be managed based on the required authentication assurance level conforming to the requirements in Sec. 7 of [15], including termination and automated logout.
1656 1657 1658 1659 1660 1661
DSSS-AM-C17 – Implement a “message of the day” and “login banner” notice: A “message of the day” or “login banner” notice should appear before every login to any storage infrastructure component or system via user interface (UI), command-line Interface (CLI), or API, if applicable. The message should include a legal notice, a warning that the user is accessing a restricted system with sensitive data, and any additional warnings or meaningful messages according to the organization’s security and privacy policies.
1662
4.3.4.4. Administrative Access
1663 1664 1665 1666 1667 1668 1669
Storage infrastructure systems are administered by designated users who use various accounts to access these systems. The administrative users and their management hosts constitute an important attack vector that can be exploited by adversaries. Since the individuals who manage the storage systems and infrastructure are generally privileged users, the allocation and use of privileged access rights should be restricted and controlled. The inappropriate use of system administration privileges can be a major contributing factor to the failures or breaches of storage systems.
1670 1671 1672
DSSS-AM-C18 – Separate security and non-security roles: A least privilege model that leverages specific roles should be implemented. According to ISO Standard ISO/IEC 27040 [6], the following roles should be implemented and used within storage technologies:
1673 1674 1675 1676 1677 1678
•
Security Administrator. This role has read-only/view and modify rights to establish and manage accounts, to create and associate roles/permissions, for audit logging configurations and contents (e.g., audit log event entries can never be changed), to establish trust relationships with IT infrastructure (e.g., shared secrets for RADIUS), to manage certificate and key stores, to manage encryption and key management, and to set access controls.
1679 1680 1681
•
Storage Administrator. This role has view and modify rights for all aspects of the storage system. No access is granted to security-related elements or data (i.e., those covered by the security administrator).
1682 1683 1684
•
Security Auditor. This role has view rights that allow entitlement reviews, the verification of security parameters and configurations, and inspections of audit logs. No access is granted to the storage, configuration, or data. 44
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
1685 1686 1687
•
Security Guidelines for Storage Infrastructure
Storage Auditor. This role has view rights that allow for the verification of storage parameters and configurations and inspections of health/fault logs. No access is granted to security-related elements or data.
1688 1689 1690
Each storage management transaction should be associated with a security or storage role. These roles can be important controls to ensure the separation of duties with respect to management capabilities.
1691 1692 1693 1694 1695
DSSS-AM-C19 – Implement the principle of least privilege: Limit the administrative rights of users to the minimum necessary. This includes specifying the minimum actions that the user can carry out and limiting the scope of these permissions to include only the relevant systems or regions. Full administrative rights should only be granted to users who have legitimate needs for these rights.
1696 1697
DSSS-AM-C20 – Limit the access rights of service accounts: Service accounts (e.g., monitoring tools) should be limited to read-only and metadata-only access.
1698 1699 1700 1701 1702
DSSS-AM-C21 – Authenticate and authorize all CLI/API access: CLI/API usage should be subject to authentication and authorization processes. If it is not possible to perform authentication or authorization, secure unauthorized access with additional security measures (e.g., using privilege management tools to restrict control to the minimum necessary commands and objects).
1703
4.3.5. Protocols (PR)
1704
DSSS-PR-C01 – SNMP security:
1705
(a) If SNMP is not in use, it should be disabled.
1706 1707
(b) Change the default, known community strings, even if SNMP is not enabled. The configured strings should meet the organizational password policy.
1708
(c) Use different community strings for devices with different levels of confidentiality.
1709
(d) Use at least SNMP version 3.
1710
(e) Enforce SNMP authentication and encryption (privacy) features.
1711 1712
(f) Do not configure SNMP with read-write access unless it is absolutely needed. In this case, limit and control the use of read-write SNMP.
1713
(g) Use access control lists to control access to devices through SNMP.
1714
(h) Periodically validate that SNMP traps are sent to authorized, intended managers.
1715 1716
(i) Refer to the Cybersecurity and Infrastructure Security Agency (CISA) TA17-156A [18] for additional guidance.
1717 1718 1719
DSSS-PR-C02 – Control IP addresses used for SNMP: When configuring SNMP, all traffic should be directed to valid organization-internal IP addresses as destinations. The validity of the configuration should be periodically reviewed.
45
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1720 1721 1722 1723
DSSS-PR-C03 – Authenticate directory, domain, and similar services: The service configurations in all storage elements (e.g., devices, switches, management workstations, management software) should be actively and periodically reviewed and adjusted (remediating any discrepancies) so that only the approved ones are used.
1724 1725 1726 1727 1728 1729 1730 1731 1732
DSSS-PR-C04 – Considerations for using standard and non-standard TCP/IP or UDP ports: Most applications and services have a default TCP/IP or UDP port that is used to connect to the application or service. However, systems often include the ability to reassign the ports. Port reassignments should be made to improve security (e.g., limit the number of ports used by an application to a small, fixed range) rather than to obfuscate an application or service, which rarely deters adversaries as tools such as port scanners (e.g., nmap) can usually identify these alternate port assignments. Using non-standard ports can make it difficult for security scanning tools to identify suspicious activities since they are designed to expect specific behaviors on standard ports.
1733 1734 1735
DSSS-PR-C05 – Use of NDMP security features: NDMP provides a means for direct transport between storage arrays and backup devices. When used, the following security features should be configured:
1736
(a) Access control over which hosts can initiate NDMP sessions
1737
(b) The challenge-response authentication (do not use the plaintext authentication option)
1738
(c) Log NDMP connection attempts
1739 1740
(d) An NMDP password that meets the organizational password policy (e.g., length, complexity)
1741
(e) Restricted NDMP-related rights
1742
(f) Encrypted NDMP control connections
1743
(g) NDMP throttling per session or per server
1744 1745
DSSS-PR-C06 – Use TLS in LDAP: Use TLS to secure LDAP connections when setting up directory service options for storage systems.
1746 1747 1748
DSSS-PR-C07 – Additional protocols: When additional protocols (e.g., SymAPI, Storage Management Initiative Specification [SMI-S], Global Name Service [GNS]) are used, the following measures should be applied:
1749
(a) Isolate traffic for data access and management from other environments.
1750
(b) Limit TCP and UDP ports.
1751
(c) Enable encryption.
1752 1753 1754 1755 1756
DSSS-PR-C08 – Use of TLS for encrypted communications: TLS protocol should be used to support encrypted communication between storage clients and servers. To prevent the use of insecure or outdated configuration, the selection and configuration of TLS protocol implementations and the choice of hashing and encryption algorithms should be based on the following guidelines (or more current versions when published):
46
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1757 1758
•
SP 800-52r2, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations [16]
1759
•
SNIA TLS Specification for Storage Systems [17]
1760
4.3.6. Storage Platform Security (PS)
1761 1762 1763
Verifying the integrity of systems or ecosystems is necessary to building trust, particularly in confidential computing and multi-cloud environments that process or handle sensitive workloads and data. Storage is often an important element of these environments.
1764 1765 1766 1767 1768 1769 1770
DSSS-PS-C01 – Support secure initialization: Storage systems and devices should support a secure initialization sequence (secure boot) during the transition from a down state to the operating state (e.g., after a power-on or reset). During the initialization phase, externally accessible processes and network interfaces should be denied access or not be available until the subjects are authenticated. Software and operating system load processes should start from a known state with secure values specified by the system administrator when the system was last operational.
1771 1772 1773 1774
DSSS-PS-C02 – Protect system secrets: The system or device should not reveal secrets (e.g., passwords, asymmetric private keys, symmetric keys, any other secret information) even in encrypted form via programmatic methods, logging operations (e.g., debug outputs), and within externally accessible configuration files or settings.
1775 1776 1777
DSSS-PS-C03 – Secure system BIOS: For storage systems/devices that include a Basic Input/Output System (BIOS), the following elements of SP 800-147 [29] guidelines should be followed:
1778
(a) Approved BIOS update mechanisms
1779
(b) BIOS update authentication
1780
(c) Secure local update (optional)
1781
(d) Integrity protection
1782
(e) Non-bypassability
1783
4.3.6.1. Firmware Security
1784 1785 1786 1787
A platform’s firmware code and critical data should always be in a state of integrity to ensure that a computing system can be operated free from malware. Broadly speaking, the platform is comprised of the hardware and firmware necessary to boot the system to a point at which software or an operating system can be loaded [24].
1788 1789 1790
DSSS-PS-C04 – Protection and update of firmware code: For all platform devices that protect firmware code and critical data, the following elements of SP 800-193 [24] guidelines should be followed:
1791
(a) Protect and update of mutable code
47
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1792
a. Authenticated update mechanism
1793
b. Integrity protection
1794
c. Non-bypassability
1795
(b) Protection of immutable code
1796
(c) Runtime protection of critical platform firmware
1797
(d) Protection of critical data
1798
(e) Non-bypassability
1799
4.3.6.2. Debugging/Diagnostic Interfaces
1800 1801 1802 1803 1804
DSSS-PS-C05 – Disable debugging ports: All debug ports on systems/devices should be disabled before the system/device leaves the factory. Alternatively, the ports should only be accessible in the field after a successful exchange of a challenge-response mechanism using an asymmetric cryptographic scheme (see SP 800-63). The debugging port state should be reset to inaccessible on any reset or power cycle.
1805 1806 1807 1808 1809 1810 1811
DSSS-PS-C06 – Sensitive information in telemetry/debugging logs: By design, systems/devices should not include user data, passwords, keys, or any secret or sensitive information in any telemetry or debug log pages. Prior to supplying telemetry or debugging logs to third parties (e.g., vendors), the contents should be inspected to confirm that no sensitive data is present. When such a determination cannot be made (e.g., the contents are in a binary form or encrypted), then the telemetry or debugging data should not be provided to a third party until there is sufficient assurance that there is no sensitive data in the content.
1812
4.3.6.3. Attestation
1813 1814 1815
Attestation allows platforms to determine whether a device/component is permitted to operate. Devices that fail authentication or integrity checks can be isolated before they affect system stability or security.
1816 1817 1818 1819 1820
DSSS-PS-C07 – Enhance trustworthiness with attestation: When attestation is an element of a storage system or device’s security, it should function as an attester that reports its identity and measurements to the verifier (e.g., host, server), which collects and verifies them. The requester should compare the returned measurements to known values and use the comparison results to make decisions on the trustworthiness of the storage.
1821 1822 1823 1824 1825
DSSS-PS-C08 – Anatomy of a trusted attester: An attester is a collection of hardware, software, firmware, and a root of trust (RoT), which should have the ability to provide reliable evidence of trustworthiness (i.e., measurements) to the verifier. Each attester device must have an RoT to calculate measurements of the security state of the attester device (e.g., firmware digests, boot parameters).
1826 1827
DSSS-PS-C09 – Use SPDM for storage attestation: The Security Protocol and Data Model (SPDM) [28] enables access to low-level security capabilities and operations by specifying a 48
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1828 1829 1830 1831
managed level for device authentication, firmware measurement, and certificate management. Storage systems/devices should use SPDM (version 1.4 or later) to provide hardware identity through a certificate as well as firmware identity (i.e., firmware code and configuration data), which can be used by hosts/servers to assess the trustworthiness of the storage.
1832
4.4. Data Protection and Recovery (DPRC)
1833 1834 1835
Section 2.7.5 discusses the objectives and associated activities of data protection, three facets based on the range of objectives, and primary controls from the point of the view of the storage facet. To reiterate, these controls are:
1836
•
Data backup and recovery
1837
•
Replication technologies
1838
•
Point-in-time copies and snapshots
1839 1840 1841 1842 1843
DPRC-GN-C01 – Data protection configuration management: The data protection configuration management (e.g., backup, point-in-time copies, replication) should be centrally managed and separated from the data consumption plane. In particular, servers and clients should not be allowed to change their own data protection configuration. This should not be interpreted as excluding redundancy mechanisms that protect against a single point of failure.
1844 1845 1846
DPRC-GN-C02 – Design data protection for recovery: Data protection mechanisms (e.g., backups, replication) should be designed with quick recoveries in mind rather than just the preservation of data. Specific RTOs and RPOs should be included in these designs.
1847
4.4.1. Storage Backups (SB)
1848 1849 1850
DPRC-SB-C01 – Availability of all relevant software and hardware components: All of the relevant software and hardware components (e.g., drivers, firmware) used to run the system should be backed up, protected, and available for a restore operation.
1851 1852 1853 1854 1855 1856
DPRC-SB-C02 – Elected backup and data copy technologies and media should match organizational RTO: RTO is a KPI used to define the expected recovery speed. The ability to meet RTOs should be examined holistically, including all dependent and related components (e.g., restoration of data, configuration files, encryption keys) while also balancing the actual recovery speed that is desired with the cost that it would take to align all of the dependent components to enable this expected recovery speed.
1857 1858
DPRC-SB-C03 – Test restore to ensure RTO: Perform a periodic test restore to validate that it is completed successfully and meets the desired time frame.
1859 1860 1861
DPRC-SB-C04 – Validate health of backup copies: Periodically validate that the backup copies are in good health. This includes checking that there are no relevant logged errors and that the backup and data copy media are in a healthy state.
49
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1862 1863 1864
DPRC-SB-C05 – Enable the separate restoration of data and application: The data should be separated from the application so that it can be restored without restoring infected code or software.
1865 1866 1867 1868
DPRC-SB-C06 – Use data backup measures and operations securely: The backup approach (e.g., measures, operations) should provide adequate and appropriate protections against data breaches (e.g., encryption, access controls). Such activities are often handled through a chain of trusted individuals and vendors.
1869
4.4.2. Storage Replication and Mirroring (RM)
1870 1871 1872 1873
DPRC-RM-C01 – Synchronous and asynchronous replication: In both synchronous and asynchronous replication, the same level of data protection (e.g., encryption of data at rest, access restrictions) that is used in the primary storage should be carried over to the secondary storage.
1874 1875 1876 1877
DPRC-RM-C02 – Eliminate unnecessary replication trust between storage devices: When arrays have shared replicated volumes, their privileges with respect to one another should be limited to the volumes they share. When arrays do not have shared replicated volumes, disable the replication trust relationship between them.
1878 1879 1880 1881
DPRC-RM-C03 – Secure replication/mirroring traffic: The confidentiality and integrity of data in transit during replication and mirroring should be protected using encryption. This recommendation can be relaxed when appropriate mitigating controls exist (e.g., mirroring over a short distance within the same enclosure or server room) (see ENKM-ET-C03).
1882 1883 1884 1885 1886 1887 1888 1889
DPRC-RM-C04 – Automated I/O suspension: Automated I/O suspension should be enabled for synchronous replication if the replica cannot be allowed to fall behind the primary data. Enabling this feature implies that the primary storage device will disallow any write operations on the data it stores if its synchronization with the secondary storage server is lost, and it can only resume processing when synchronization is restored. For this reason, enforcing this feature comes at the cost of opening an additional attack vector. An adversary who is aware of or suspects that it is in use can trigger primary storage denial of service by attacking the replication network paths. This trade-off should be carefully weighed.
1890 1891
DPRC-RM-C05 – Eliminate obsolete replicas: Obsolete replicas should be removed to reduce opportunities for data exposure.
1892
4.4.3. Storage Snapshots (SS)
1893 1894 1895 1896
Point-in-time copies refer to a variety of storage technology internal data copy mechanisms that can be used to create a copy of original data as it appeared at a past point in time. This includes storage arrays, built-in copy-generation tools (e.g., snapshots, clones), file system-level copies, database-level copies, cloud storage pool copies, and more.
1897 1898
DPRC-SS-C01 – Configure point-in-time copies: When point-in-time copies (e.g., snapshots) are used as part of the backup scheme, they should be configured accordingly:
50
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1899 1900 1901
(a) To meet the RPO of the target data sets in the snapshot. For example, if the business or compliance standards are that no more than five minutes of committed data can be lost in recovery, then the snapshot interval should be five minutes or less.
1902 1903
(b) To meet retention obligations. For example, if hourly copies are needed for at least 48 hours, confirm that a sufficient number of hourly snapshots is preserved.
1904 1905
DPRC-SS-C02 – Eliminate obsolete snapshots/clones: Obsolete snapshots or clones should be removed to reduce opportunities for data exposure.
1906
DPRC-SS-C03 – Snapshot security: Snapshot security should:
1907 1908
•
Align the snapshot approach with its associated recovery strategy, especially for business/mission-critical data
1909
•
Protect snapshots from changes (e.g., read only)
1910
•
Provide adequate protections against unauthorized access (e.g., encryption)
1911
4.4.4. Cyber Recovery Systems (CR)
1912 1913 1914 1915 1916 1917 1918
Incident response planning is an important part of cybersecurity. The NIST Framework for Improving Critical Infrastructure Cybersecurity [19] provides a comprehensive discussion of the role of incident response in cybersecurity program management as well as guidelines on building a framework for cybersecurity improvement. Storage-related incidents should be handled as an integral part of the organization’s incident response process, including isolation, root-cause analysis, defining and managing a response plan, testing, and periodical process review and refresh.
1919 1920 1921
DPRC-CR-C01 – Disable all unnecessary services and protocols: Unnecessary services and protocols should be disabled on cyber-attack recovery storage systems. In environments where API or CLI are sufficient for management, interactive web interfaces should also be disabled.
1922 1923 1924
DPRC-CR-C02 – Recovery assets immutability during incident management: To avoid compromising cyber recovery copies, immutability protections should be used on the cyber recovery copies during incident management.
1925 1926 1927
DPRC-CR-C03 – Validate the hygiene of recovered compute components: Verify that recovered executables, applications, containers, and operating system images are free from infection prior to deploying them in production.
1928 1929 1930 1931 1932 1933 1934 1935
DPRC-CR-C04 – Restrict access to cyber-attack recovery systems: For sensitive information, cyber-attack recovery copies and their systems should not be accessible to regular IT staff but only to a single person (e.g., CISO) or a very narrow group of executives or security managers who use credentials separate from those used for other day-to-day duties. This ensures that if the credentials of an IT administrator are compromised, the adversary cannot use those credentials to access cyber-attack recovery copies. This restricted team can have access to the cyber-attack recovery copies, but an even smaller subset should have administrative rights that include granting permissions to other users.
51
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1936 1937 1938 1939
DPRC-CR-C05 – Off-site storage: Cyber-attack recovery copies should be stored off-site rather than where the production data is stored. If adversaries have physical access to the production site or manage to compromise the physical site, they cannot access or compromise the off-site cyber-attack recovery copies.
1940 1941 1942 1943 1944 1945 1946
DPRC-CR-C06 – Use an independent, full baseline copy: Backup systems often make use of incremental backups that capture changes to the data relative to a baseline copy. These incremental copies cannot be used during recovery without the baseline copy. For certain types of backup schemes (e.g., snapshots), only incremental copies are used (i.e., the baseline copy is the production data itself). To handle a recovery scenario properly, dependencies between copies should be accounted for, and sufficient isolation between different types of copies should be maintained. In particular:
1947 1948
(a) Replicated disaster recovery copies should have no dependency on production baseline data.
1949 1950 1951 1952
(b) Cyber-attack recovery copies should have no dependency on production baseline data. Dependency on disaster recovery baseline data is allowed only if those copies are properly isolated from production baseline data and meet the recommendations in PSDS-IS-C01, PSDS-IS-C02, and DPRC-CR-C04.
1953 1954 1955 1956 1957 1958
DPRC-CR-C07 – Independence from hosts and applications: Cyber-attack recovery copies should not be mounted, exported, or mapped to a host or application, and they should be restored (pushed) onto an isolated staging environment (or air-gapped) rather than directly onto the target hosts or applications. A less secure option is to allow the target hosts or applications limited read-only access (e.g., mapping, mounting) during restore only, and remove such access as soon as restoration is complete.
1959 1960 1961 1962 1963 1964 1965 1966
DPRC-CR-C08 – Consider setting up an air gap: Organizations should set up an air gap around the cyber-attack recovery copies of sensitive data. Strict implementations of air-gapping should provide full physical and network-level separation. Certain storage technologies also introduce less strict isolation technologies that enable shutting down data ports and opening them during a limited time for the periodic sync with the production system. It is important to weigh the effectiveness of each of those techniques based on the value of the data and the capabilities of the adversary. When strict implementations are chosen, attention should be paid to circumventing known vulnerabilities of air-gaped systems, such as:
1967 1968 1969
(a) Preventing visual, audible, and thermal signal transmission between air-gapped systems and other equipment (e.g., maintaining sufficient distance, using dampening and/or sufficient physical distance)
1970
(b) Preventing any potential wireless transmission capabilities in air-gapped equipment
1971
(c) Disabling exposed data ports (e.g., USB, network)
1972
(d) Using power conditioning or separate power circuits
1973 1974 1975
DPRC-CR-C09 – Cyber hygiene of data copies: For mission-critical information, cyber-attack recovery copies should be scanned with various anti-malware scanning tools and vulnerability scanners. Ideally, all copies should be scanned. If that is not possible, scan a subset of the 52
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
1976 1977
copies, and keep a record of those copies scanned and secure. Cyber hygiene tools include antimalware, vulnerability scanning, and security analytics.
1978 1979 1980 1981 1982 1983 1984 1985
DPRC-CR-C10 – Perform periodic audits: The above recommendations should be reviewed as part of a periodic audit to check the completeness of copies, reevaluate dependencies, address software and hardware needs, and consider the suitability of technology to support recovery speed, RPO, retention, health-checking, DR plan, and cyber hygiene. Gaps should be identified, tracked, and remediated. The frequency of auditing should be no less than once per year and match the sensitivity and value of protected data. Sensitive and high-value storage systems should be audited at least a quarterly and after every major change, whichever comes first. Audit results should be documented.
1986 1987 1988 1989
DPRC-CR-C11 – Secure cyber-attack recovery backups: While many organizations implement backups for disaster recovery and business continuity purposes, some organizations also perform special backups to assist with cyber-attack recovery (e.g., ransomware attacks). In addition to the normal backup security measures, cyber-attack recovery backups should:
1990 1991
•
Not be accessible to regular IT staff but rather a very narrow group of executives or managers
1992 1993
•
Be retained for much longer periods of time to allow for investigations and deal with attacks that have remained latent until triggered much later
1994
•
Be stored off-site and separate from where production storage backups are stored
1995 1996
•
Use independent, full backup copies on a regular basis (i.e., have no dependencies on production baseline data)
1997 1998
•
Be restored onto an isolated staging (or air-gapped) environment rather than directly onto the target hosts or application
1999
•
Use immutable storage
2000
4.5. Storage Networking and Technologies (SNTC)
2001
4.5.1. Block-Based Storage Networking (BK)
2002 2003 2004
SNTC-BK-C01 – Block-device access control: The hosts that can access a set of SAN storage devices should be restricted through zoning (i.e., software or hardware) and masking to limit the access.
2005 2006 2007 2008
SNTC-BK-C02 – Block-device copy and replica access control: The hosts that can access a set of SAN-replicated block-devices, snapshots, and other types of point-in-time copies of such blockdevices should be restricted through zoning and masking. In many cases, a host that is granted access to a device should not be allowed to access a copy.
2009 2010 2011
SNTC-BK-C03 – Use zoning is SAN-switched fabrics: The zoning should be implemented in a switched SAN fabric based on sound logic, particularly as it relates to the separation of environments and traffic type, which should be separated to the maximum possible extent, by:
53
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2012
(a) Environment (e.g., development versus test versus production)
2013
(b) Type of traffic (e.g., data access versus management versus replication versus backup)
2014
(c) Type of hosts (e.g., virtualized versus physical)
2015
(d) Storage device type (e.g., tape versus disk)
2016 2017 2018
SNTC-BK-C04 – Software zoning implementation: When software zoning is implemented, hosts should only be allowed to connect to storage devices provided by the simple name server (SNS) by looking it up at the software zoning table and not directly using device discovery.
2019 2020 2021
SNTC-BK-C05 – Controlling devices that can join fabric: The policy specification feature in SAN that enables the creation of an allowable list of switches, arrays, and hosts that can join the fabric should be leveraged where applicable.
2022
4.5.1.1. Fibre Channel
2023 2024 2025
A SAN fabric may be divided into “zones”, which are groupings of ports that are allowed to communicate with each other. One level of security is to construct zones to prohibit communication between particular ports.
2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036
•
Soft zoning – Soft zoning uses filtering implemented in Fibre Channel switches to prevent ports from being seen from outside of their assigned zones. The security vulnerability in soft zoning is that the ports can still be accessible if the user in another zone correctly guesses the Fibre Channel address. In this case, the FC switch will place a host WWN in a zone without evaluating the port numbers in the FC switch, which were used for connection. World Wide Port Name (WWPN) identification is considered more secure than port number identification (used in hard zoning) because any device that is physically connected to a port can grant storage access to an unauthorized host. If the SAN spans across facilities with different physical security controls, and if there is a risk that physical ports can be accessed by unauthorized individuals, soft zoning may be preferable.
2037 2038 2039 2040 2041
•
Hard zoning – Hard zoning uses physical port numbers on SAN switches, thereby physically blocking access to a zone from any device outside of the zone. This type of zoning protects from WWN spoofing attacks as it does not rely on host identity. If the organization’s physical access is thoroughly protected (i.e., it is improbable that an intruder will access a physical port), this method may be preferable.
2042 2043
SNTC-BK-C06 – FC host and switch authentication: Every host and storage switch should have a unique identity and should be authenticated before joining the network (e.g., FC-SP-3).
2044 2045 2046
SNTC-BK-C07 – Use an approved FC PKI mechanism: Use an organization-approved and certified centralized PKI system for the management of switch certificates (e.g., Fibre Channel Certificate Authentication Protocol or FCAP) rather than the devices’ self-signed certificates.
2047 2048 2049
SNTC-BK-C08 – Use Fibre Channel zoning: Zoning should be used in FC SAN fabrics with a preference for hard zoning. Default zones and zone sets should be used with care (assume a least privilege posture). Determine whether basic zoning is a strong enough security measure 54
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2050 2051
for the target environment, and if not, use stronger techniques like FC-SP-3 zoning, where supported by the vendor.
2052 2053 2054
SNTC-BK-C09 – A blended approach to FC zoning: Implement a zoning approach that blends different types of zoning mechanisms. This is preferable to simply zoning using a single type (i.e., host, switch, and storage device):
2055 2056 2057 2058 2059 2060 2061
(a) Host-based zoning mechanisms control what storage resources or devices are visible to an application on a host as well as the devices that it can access. At the lowest level, the masking capability in an HBA’s firmware or driver can be used to control whether the host can interact with any storage device. At the next level, OS capabilities can be used to control which devices the host tries to mount as a storage volume. Finally, the host centralized management software for volume management (e.g., LVM), clustering tools, and the file system can be utilized to control device access by applications.
2062 2063 2064 2065 2066
(b) In switch-based zoning, the switches (especially the FC switches) have the capability to specify which devices on which ports can access other devices or ports. Port-based zoning uses hardware to enforce zoning and is therefore also called “hard zoning.” In other words, switches should support zone control at the port WWN’s level rather than at the switch (node) WWN level.
2067 2068 2069 2070
(c) In storage device-based zoning, the storage array is configured with a list that shows which hosts (even more specifically, which HBA ports) can access which block devices and on which ports. Access requests from unlisted hosts or HBA ports are ignored or rejected.
2071 2072 2073
(d) If the zone set feature is available, it should be leveraged. This will help create multiple zones dedicated to a particular purpose, such as testing, dynamic reconfiguration, backup, and maintenance.
2074 2075 2076 2077
SNTC-BK-C10 – FC masking recommendation: Masking refers to making a block device visible or invisible to hosts. Masking should be as close to the data as possible and as far from the data consumer or client as possible (e.g., favor array over switch masking, core switch over edge switch, and switch over HBA).
2078 2079 2080
SNTC-BK-C11 – A backup of FC switch configuration data: Create a backup of the switch’s configuration data, including zone configuration file. The backup should be kept outside of the SAN switches to enable redeployment upon erroneous or malicious corruption or deletion.
2081
SNTC-BK-C12 – Limit FC switch management capabilities to the minimum necessary:
2082 2083 2084
(a) When implementing the SAN fabric, there should be well-defined policies that specify and minimize the set of switches that are authorized to distribute configuration data while providing acceptable redundancy.
2085 2086
(b) Unnecessary configuration management permissions and services (e.g., password distribution) should not be enabled.
55
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2087 2088 2089
SNTC-BK-C13 – Limit communication between FC switches: Communication between SAN switches should be limited based on security policies while ensuring that switches can only communicate with switches that are necessary.
2090 2091
SNTC-BK-C14 – Disable unused FC SAN ports: Unused FC SAN ports should be persistently disabled to prevent the accidental or deliberate connection of unauthorized equipment.
2092 2093 2094 2095 2096 2097
SNTC-BK-C15 – Audit FC SAN security configuration: Over time, some security changes might not be reliably propagated across all switches in the fabric. FC SANs should be periodically reviewed (similar to IP and Ethernet-based networking) to assess their security, identify and prioritize gaps, and define a remediation plan. Security review should be performed at least annually, and in sensitive environments, at least quarterly or after any major change, whichever comes first. Audit results should be documented.
2098 2099 2100 2101
SNTC-BK-C16 – Confidentiality protections for Fibre Channel storage: Data-at-rest encryption at the LUN-level should be used to prevent access by unauthorized parties (e.g., service provider personnel, adversaries). Fibre Channel connections that leave the protected area (e.g., confines of a physically controlled data center) should be encrypted using ESP_Header.
2102 2103 2104
SNTC-BK-C17 – Sanitization for Fibre Channel-based storage: The Fibre Channel storage should include storage sanitization capabilities for LUNs (i.e., logical sanitization) and the underlying storage technologies (i.e., media-aligned sanitization).
2105
4.5.1.2. NVMe Over Fibre Channel (FC-NVMe)
2106 2107
The NVMe-oF standard defers NVMe/FC-specific security concerns to the FC-SP-3 technical standard, which includes protocols to enhance Fibre Channel security in several areas.
2108 2109 2110
SNTC-BK-C18 – Use NVMe-oF authentication: NVMe-oF supports two high-level types of authentications: fabric secure channel and in-band authentication. One or both authentication mechanisms should be used.
2111 2112 2113
SNTC-BK-C19 – Use NVMe/FC security: Security controls for NVMe/FC can include some of the controls used with FC SAN controls (see Sec. 4.5.1.1). For NVMe/FC, the following should be used:
2114
•
Adequate physical security, including segregated networks
2115
•
FC zoning to partition the FC fabrics
2116
•
LU masking on the storage to restrict access to specific LU
2117 2118
•
Authentication of Fibre Channel devices, secure key exchange, and secure (i.e., encrypted) communication between Fibre Channel devices
2119
4.5.1.3. IP Storage Networking
2120 2121
IETF RFC 3723 provides additional useful information on both iSCSI and FCIP. In addition, IETF RFC 7146 provides important security updates to IETF RFC 3723 and IETF RFC 3821.
56
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
2122 2123
Security Guidelines for Storage Infrastructure
SNTC-BK-C20 – Segregate iSCSI networks: For iSCSI networks, access and protocols should be controlled by:
2124
•
Segregating iSCSI interfaces from general-purpose LANs
2125 2126
•
Using virtual local area networks (VLANs) when the use of physically isolated LANs is not an option
2127
SNTC-BK-C21 – Secure iSCSI networks: iSCSI security measures should be used, including:
2128 2129
•
Bidirectional CHAP authentication using random challenges (i.e., not repeated) for both initiators and targets
2130 2131
•
IPsec to secure the communication channel when sensitive or high-value data can be exposed
2132
•
Control iSCSI initiator access by filtering based on source IP addresses and protocols
2133 2134
•
Internet Storage Name Service (iSNS), SLP, and DNS infrastructure with appropriate security controls to avoid indirect attacks
2135 2136 2137
Fibre Channel over IP (FCIP), defined in IETF RFC 3821, is a pure Fibre Channel encapsulation protocol. It allows for the interconnection of islands of Fibre Channel Storage Area Networks through IP-based networks to form a unified SAN.
2138 2139
SNTC-BK-C22 – Secure FCIP networks: FCIP network access and protocols should be controlled by:
2140 2141
•
Setting up the peer-to-peer relationship between FCIP entities while recognizing that the security policies are applied uniformly
2142
•
Using a private IP network used exclusively by the FCIP entities, whenever possible
2143
•
Performing cryptographic authentication and data integrity at a minimum
2144
•
Protecting sensitive data by appropriate confidentiality measures
2145 2146
SNTC-BK-C23 – Secure NVMe/RDMA networks: Security Controls for NVMe/RDMA should use in-band authentication provided by DH-HMAC-CHAP.
2147 2148 2149
SNTC-BK-C24 – Confidentiality protections for IP storage: Data-at-rest encryption measures should be used to protect the confidentiality of sensitive or high-value data recorded on IP storage devices or media.
2150 2151
SNTC-BK-C25 – Sanitization for IP-based storage: For IP-based storage, storage sanitization measures include the following:
2152 2153
•
Media-aligned sanitization should be used for IP storage media and storage device for sensitive and regulated data.
2154 2155
•
Logical sanitization should be used for virtualized IP storage, especially when the actual storage devices and media cannot be determined.
57
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2156 2157 2158
SNTC-BK-C26 – IP storage network separation: For storage-related communication over IP networks, sound logic should be applied to the separation of environments and traffic type. Sensitive environments should be separated to the maximum possible extent based on:
2159 2160
(a) Type of traffic: Data access protocols versus management versus replication versus backup versus host and application networking.
2161 2162 2163 2164 2165 2166
(b) In sensitive environments, further separate the management traffic of different solutions, vendors, and technologies. For example, if two or more storage solutions are in use (e.g., different array technologies, Server-Based SAN products, switch technologies, storage virtualization, or any combination thereof), and each one has a separate set of management tools, management traffic for each environment should be separated from the others.
2167
(c) Data access protocols (e.g., iSCSI).
2168
(d) Type of servers or hosts accessing data: Virtualized hosts versus physical hosts.
2169 2170 2171
SNTC-BK-C27 – Isolate IP/Ethernet management ports: The IP or Ethernet management ports of SAN switches should reside in an isolated subnet, including separation from subnets used for data access between hosts and storage and for host-to-host communication.
2172 2173 2174 2175
SNTC-BK-C28 – Enable device IP access control: With respect to IP network accessibility, storage device security features that regulate IPs, ports, and protocols should be turned on and configured on all storage devices, where applicable. This includes but is not limited to built-in firewall rules, IP filtering, and access lists in order to:
2176 2177
(a) Control and limit data access between only the hosts or applications and the storage objects they use and
2178 2179
(b) Separately control management IP traffic between management hosts, management applications, and the relevant storage management interfaces they use.
2180 2181 2182 2183
SNTC-BK-C29 – Enable network IP access control: Restrictions should be applied at the network level (e.g., routing, firewall, access lists, Virtual Private Cloud [VPC] security groups, serverbased SAN clients) to restrict all traffic types (e.g., data access, management) to allowed IP addresses and TCP/UDP ports and protocols only:
2184
(a) Between hosts or applications and the storage objects they use and
2185 2186
(b) Between management hosts and applications and the relevant storage management interfaces of storage objects they manage.
2187 2188
SNTC-BK-C30 – Limit iSCSI ports: Hosts on the iSCSI network should be prevented from accessing any TCP ports other than those designated for iSCSI on that network.
2189 2190 2191 2192 2193
SNTC-BK-C31 – Use iSCSI authentication: Using one of the supported methods to authenticate iSCSI initiators upon opening a session (e.g., CHAP, server routing protocol, Kerberos, Simple Public-Key GSS-API Mechanism [SPKM] 1/2). When using CHAP, prefer using two-way authentication over one-way authentication while noting that the use of authentication does not provide encryption or integrity protection to the channel.
58
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2194
4.5.1.4. NVMe over TCP (NVMe/TCP)
2195 2196
SNTC-BK-C33 – Use NVMe/TCP Security: Security controls for NVMe/TCP should be used, including:
2197 2198
•
Authentication only (requires authentication secrets provisioning, one per entity) with DH-HMAC-CHAP
2199 2200 2201
•
Secure channel concatenated to an authentication transaction in which the authentication transaction generates an ephemeral pre-shared key to be used by the secure channel protocol
2202 2203
•
Secure channel alone (requires provisioning a pre-shared key for each pair of entities allowed to communicate)
2204
•
Appropriate communications security with NVMe-oF solutions such that:
2205
o TLS is used and no version of the Security Socket Layer (SSL) Protocol is used
2206 2207
o NVMe-oF solutions based on NVMe-oF Revision 1.1 do not use TLS protocol versions less than 1.2
2208 2209 2210
o NVMe-oF solutions based on the NVMe Base Revision 2.0 specification and the NVMe over TCP Revision 1.0 specification do not use TLS protocol versions less than 1.3
2211
4.5.2. File-Based Storage Networking (FL)
2212
4.5.2.1. Network File System (NFS)
2213 2214
SNTC-FL-C01 – NFS network access and protocols: NFS network access and protocols should be controlled by:
2215 2216
•
Enabling NFS only if required to eliminate it as a possible attack vector available to an adversary
2217
•
Using NFSv4 (or later versions) whenever possible and limiting NFSv3 usage
2218
•
Filtering client and management access by IP address for additional security
2219 2220
SNTC-FL-C02 – Apply NFS authentication: Authentications should be applied from all NFS access:
2221
•
Employ user-level authentication whenever possible (e.g., NFSv4 with Kerberos V5)
2222
•
Use Kerberos authentication for NFSv3
2223
•
When appropriate, use Kerberos Safe and Private modes to sign and encrypt NFS traffic
2224 2225 2226
SNTC-FL-C03 – Apply NFS access controls: Access controls should be applied to NFS exported file systems to: •
Configure the NFS server to export file systems explicitly for the authorized users 59
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2227
•
Configure the NFS server to export file systems with minimum required privileges
2228 2229
•
Grant permissions at a finer level of granularity rather than a coarser one (e.g., file over folder, label over share)
2230
•
Avoid granting root or administrator access to files on network file systems
2231
•
Assign NFSv4 ACLs correctly
2232
SNTC-FL-C04 – Secure NFS client access: NFS client behaviors should be restricted to:
2233
•
Filter client access to NFS shares whenever possible
2234
•
Use encrypted communications (e.g., IPsec or TLS) for data access
2235 2236
•
Disallow NFS clients to run programs that provide temporary elevated permissions during execution on exported file systems
2237
SNTC-FL-C05 – Secure data on NFS servers: Data on NFS servers should be secured by:
2238 2239
•
Ensuring that export file systems are in their own partitions to prevent system degradation by an adversary writing to an exported file system until it is full
2240
•
Encrypting data at rest when necessary
2241
•
Disallowing NFS exports of administrative file systems
2242
•
Guarding against malware (e.g., viruses, worms, rootkits)
2243 2244 2245 2246
SNTC-FL-C06 – Secure NFS by restricting root access: This includes using the “nosuid” option and avoiding “no_root_squash” to prevent programs from being executed as a root user on the client and the modification of shared files by remote root users. In general, NFS clients should not be allowed to run “suid” and “sgid” programs on exported file systems.
2247 2248 2249
SNTC-FL-C07 – NFS “read only” mode: For files that are to be used in the read-only mode in NFS, the mount configuration for corresponding NFS shares should always have the “noexec” option.
2250 2251
SNTC-FL-C08 – NFS export of administrative file systems should not be allowed: This includes the ‘/’ file systems and restricted operating system or storage array system folders.
2252 2253 2254 2255
SNTC-FL-C09 – Disable NFS non-authenticated access: Users that need to authenticate should be disabled (e.g., Anonymous, null, guest, “public access”). An exception may be provided to allow organization-critical functions (e.g., network discovery), in which case, this class of users should be mapped to the “nobody” user group and not to “ID 0.”
2256
4.5.2.2. Server Message Block (SMB)
2257 2258
SNTC-FL-C10 – Apply SMB networking controls: The following networking controls should be used for SMB-based NAS:
2259
•
Turn off low-security session negotiation protocols, and use Kerberos instead.
2260
•
Maintain up-to-date patch levels. 60
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2261
•
Use SMB signing for clients and the NAS device.
2262
•
Access directory services securely.
2263
•
Use one-way trusts from leaf domains to parent domains, when possible.
2264
•
Control SMB network access and protocols by:
2265 2266
o Enabling SMB only if necessary. This eliminates it as a possible attack vector available to an adversary.
2267
o Encrypting client data access when necessary.
2268 2269
SNTC-FL-C11 – Apply SMB access controls: Access controls should be applied to SMB exported file systems to:
2270 2271
•
Disable unauthenticated access to SMB shares and NAS devices (i.e., restrict Anonymous access)
2272
•
Disable Guest and Everyone access to all SMB shares
2273
•
Implement authentication and access control via a centralized mechanism (e.g., LDAP)
2274
SNTC-FL-C12 – Secure data on SMB servers: Data on SMB servers should be secured by:
2275
•
Enabling SMB auditing whenever possible
2276
•
Continually reviewing content placed in SMB shares and relevant access controls
2277
•
Encrypting data at rest when necessary
2278
•
Guarding against malware (e.g., viruses, worms, rootkits)
2279
•
Using SMB with strong authentication (Kerberos)
2280 2281 2282
SNTC-FL-C13 – Disable insecure versions of SMB: Outdated, unrecommended, or unsecured protocol versions (e.g., SMB v1 or v2, CIFS) should be blocked and disabled on both the client side and the server side. SMB version v3 or later should be used.
2283 2284 2285
SNTC-FL-C14 – Restrict SMB “full control” permissions: When SMB is used, “Full Control” permissions should not be granted to any user since the recipient can use it to modify the permissions, thus resulting in the leakage of privileges.
2286
4.5.3. Object-Based Storage Networking (OB)
2287 2288
SNTC-OB-C01 – Permission for default zone: The permission for default zone (which may be product-specific) should always be configured as “deny all.”
2289 2290
SNTC-OB-C02 – Non-public storage objects: Block any public access to non-public storage objects, particularly from the internet.
2291 2292
SNTC-OB-C03 – Public access: For storage objects that need public access, sufficient controls should be implemented, including:
2293
(a) Minimizing access
61
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2294 2295
(b) Using physically and logically separate storage subnets and, preferably, separate storage devices and pools from those used for non-public storage objects
2296
(c) Addressing protection from DoS attacks
2297 2298
(d) Cached copies (e.g., using content delivery network, replicas, and proxies) retaining at least the same security characteristics as the source data
2299
(e) Addressing regulatory obligations (e.g., confidentiality, storage location restrictions)
2300
(f) Any additional applicable security controls (e.g., encryption, authentication)
2301 2302
SNTC-OB-C04 – Restricting access to object storage data of all types (e.g., files, objects) to the minimum possible: Follow the least privilege principle, including:
2303 2304 2305
(a) Access to object storage data through any protocol (e.g., SMB, NFS, public cloud object storage) should be restricted based on client Ips, relevant subnets, and the ports/protocols being used.
2306 2307
(b) If supported, finer-grained access control mechanisms (e.g., by role, ID, labels, accounts, VPC, VPC endpoints) should also be used.
2308 2309 2310
(c) Access should only be granted to centrally managed users and roles (e.g., those found in enterprise directories or approved commercial services) and not to local users of the specific system.
2311
(d) The default access to any share should be set to “deny all” or equivalent.
2312 2313
(e) The default shares should be disabled or removed. If there is a specific purpose for using them, the access rights should be restricted to the minimum necessary.
2314 2315
(f) The access rights (e.g., read, write, execute, modify, delete, view ACLs, change ACLs), should be individually assigned on a need-to-know basis.
2316 2317
(g) If the feature to define object storage ACLs is available, it should be leveraged in addition to the use of native OS user, group, or admin permission models.
2318 2319 2320
(h) If a policy definition feature to define file-level access patterns is available, it should be leveraged. The feature to detect violations to the pattern, which sends notifications, should also be implemented.
2321 2322
(i) Security mechanisms (e.g., authentication, key management) should be aligned with tenants on the object-based storage.
2323 2324 2325 2326 2327
SNTC-OB-C05 – Use object protection to prevent unauthorized deletion: For sensitive information, when supported, use advanced controls to prevent unauthorized object deletion (e.g., MFA for object deletion, locking objects against deletion). Data objects should have appropriate data immutability protections enabled to guard against malicious accidental deletions or encryption (e.g., ransomware).
2328 2329
SNTC-OB-C06 – Secure transfer of objects: Transport security (e.g., IPsec, TLS) should be used for all object-based storage transactions.
62
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2330 2331 2332
SNTC-OB-C07 – Confidentiality protections for stored objects: Data-at-rest encryption at the object or tenant level should be used to prevent access by unauthorized parties (e.g., service provider personnel, adversaries).
2333 2334
SNTC-OB-C08 – Sanitization for object-based storage: Object-based storage should include storage sanitization capabilities for tenants and the underlying storage technologies.
2335
4.6. Encryption and Key Management (ENKM)
2336 2337
ISO/IEC 27040 identifies multiple issues related to storage-based encryption solutions that should be addressed, such as:
2338 2339
•
Encryption can adversely impact other security mechanisms (e.g., inspection of data, antivirus).
2340 2341
•
Data can be permanently lost if anything goes wrong with data handling, data transformations, key management, or the actual encryption.
2342 2343 2344
•
Encryption can be computationally intensive, necessitating non-trivial computational resources. Embedded encryption within storage devices (e.g., SSD and HDD) may offset some of the computational impacts.
2345 2346 2347
•
Centralized key management may be necessary, especially when encryption is used in conjunction with out-of-region replication for business continuity/disaster recovery purposes.
2348 2349 2350
•
Encryption can diminish or negate the benefit of data reduction technologies, such as compression and/or deduplication (when such technologies are used, they should be applied before encryption – see ENKM-EN-C04).
2351 2352
•
The quality of the cryptography (e.g., security strength, quantum resistance, industrytested and accepted algorithms) can impact the actual protection offered.
2353 2354 2355
ISO/IEC 27040 further states that not all data are worth encrypting. A risk assessment can help identify sensitive and high-value data that warrant the use of encryption and assist with costbenefit analysis.
2356
4.6.1. General Storage Encryption and Key Management Controls
2357 2358 2359
ENKM-GN-C01 – Use encryption to protect sensitive, regulated, and high-value data: Encryption and appropriate key management should be used to protect sensitive, regulated, and high-value data in transit, at rest, and in use.
2360 2361 2362 2363 2364
ENKM-GN-C02 – Storage encryption provides limited confidentiality protection: Storage encryption is typically active only while the data are resident on the storage system or media (e.g., it is plaintext once it passes through the point of encryption, which occurs any time the data are accessed). Storage-based encryption should not be the primary confidentiality protection for sensitive data.
63
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2365 2366 2367 2368
ENKM-GN-C03 – Use encryption to protect administrative/management control of storage: Encryption should be used to protect the confidentiality and integrity of sensitive system software (e.g., firmware), secrets, and details (e.g., logs, dumps, telemetry) that are transmitted and/or stored.
2369 2370 2371
ENKM-GN-C04 – Limit the operational impacts of cryptography: The use of cryptography, particularly encryption, can have operational impacts on the effectiveness or efficiency of ICT infrastructure, such as:
2372
•
Increased management complexity
2373 2374
•
Diminished effectiveness of network-based data loss prevention technologies due to the use of end-to-end encryption on communications
2375 2376
•
Expanded network or storage utilization due to the inability to apply data reduction technologies (e.g., deduplication, compression techniques) on ciphertext
2377
•
Inability to apply centralized malware scanning on encrypted data
2378 2379
ENKM-GN-C05 – Security strength of cryptography: Cryptography used within storage systems and infrastructure should have at least 128 bits of security strength [20].
2380 2381 2382 2383
ENKM-GN-C06 – Use validated cryptographic modules: Cryptographic modules used to protect sensitive or regulated data should be validated using recognized criteria [32] [31]. When sensitive government data is being protected, this validation should be at least FIPS 140-3 Level 2 [32].
2384 2385 2386 2387
ENKM-GN-C07 – Comply with import/export regulation for cryptography: Cryptographic technologies can have strict regulations governing their import/export. Failure to address these regulations can expose an organization to regulatory penalties or cause catastrophic losses under certain conditions.
2388
4.6.2. Encrypting Data at Rest (EN)
2389 2390 2391 2392
ENKM-EN-C01 – At-rest encryption of sensitive data: At-rest encryption protects against a variety of data-related risks (e.g., unauthorized access, compromise in case of media loss or theft) and should be enabled for sensitive data. Encryption algorithms and modes of operations that are appropriate for storage technology should be used and can include:
2393
•
AES with the XTS mode [35] [ for HDDs and SSDs
2394 2395
•
AES with the counter with cipher block chaining message authentication code (CCM) or Galois/Counter Mode (GCM) modes [36] for tape
2396 2397 2398 2399 2400 2401
ENKM-EN-C02 – Use an appropriate point of encryption: Protecting data at rest typically involves a single point in the data path (i.e., point of encryption) that is used for encrypting and decrypting the data. This point of encryption is important because it is the location within the data path where the data are protected (i.e., ciphertext) or unprotected and usable (i.e., plaintext). The point of encryption in the storage infrastructure should be selected to address the identified confidentiality risks for sensitive data. The type of storage (e.g., block, file, object) 64
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2402 2403
can also impact the options for selecting the point of encryption. In some situations, data migrations may be necessary to take full advantage of this point of encryption.
2404 2405 2406
ENKM-EN-C03 – Create appropriate proof of encryption: Encryption can be an important protection against data breaches and instrumental to demonstrating that no data breach occurred. To fully realize the benefits of data-at-rest encryption:
2407 2408
•
The encryption mechanisms should produce appropriate records of the operational state of the encryption (e.g., activation, verification, integrity checks, re-keying).
2409 2410
•
The organization should perform regular and audited checks that encryption was properly performed and consider outside accreditation.
2411 2412
•
The organization should confirm that these records are retained (e.g., in the audit log infrastructure).
2413 2414 2415 2416
ENKM-EN-C04 – Use of data reduction technologies with encryption: When encryption is used along with compression and/or deduplication, the data reduction technologies should be applied before the encryption because ciphertext does not effectively compress. The reverse order of these techniques should be used when decrypting the data.
2417
4.6.3. Encrypting Data in Transit (ET)
2418 2419 2420 2421
ENKM-ET-C01 – Use of end-to-end encryption: When the protection of data in transit is required, it should provide end-to-end protection (i.e., a method of securing communication that prevents third parties from accessing data while it is transferred from one end system or device to another).
2422 2423
ENKM-ET-C02 – Data in transit encryption: Appropriate data-in-transit encryption should be used, including:
2424 2425 2426
(a) Block over Fibre Channel: Link encryption for FC, which is defined in ANSI/ INCITS 5452019, Information Technology – Fibre Channel - Framing and Signaling - 5 (FC-FS-5). For sensitive information, use end-to-end (i.e., host to storage) encryption.
2427 2428 2429 2430 2431 2432 2433
(b) Block over IP: IP storage traffic is subject to the same security risks as regular IP networks. By default, block-over IP protocols do not provide data confidentially, integrity, or authentication per packet. While specifications for IP storage traffic encryptions exist, current technology does not natively support it. When using blockover IP protocols (e.g., iSCSI, FCIP, proprietary protocols), IPsec tunneling should be used for exposed network segments. For sensitive information, use end-to-end (i.e., host to storage) encryption.
2434 2435 2436 2437 2438 2439
(c) File and object storage access: Data encryption in-flight options should be enabled for backup systems and remote replication whenever supported. For file access, sensitive data should be transmitted and encrypted using mechanisms, such as SMB encryption; available NFS encryption options, such as those offered by cloud vendors; or NFS over TLS using tunneling, such as ‘stunnel’. Objects should be accessed through HTTPS with TLS. 65
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2440 2441 2442 2443 2444
(d) Extended network communication beyond the boundaries of a physically protected domain: Particular attention should be paid to enable encryption on all connectivity segments that extend network communication beyond the boundaries of a physically protected domain (e.g., an ISL link between two physically separated datacenters, IP traffic over WAN or the internet).
2445 2446 2447 2448 2449
ENKM-ET-C03 – Communication between storage system components should be encrypted: Storage system component interactions should be reviewed, and available encryption options should be utilized. Encryption should be used to protect communication between storage nodes and managers, active-active storage nodes with witness devices, communication with policy servers, and antivirus servers.
2450
4.6.4. Key Management for Storage (KM)
2451 2452 2453 2454
Encryption relies on the availability and management of cryptographic keys. All communication parties should have access to the necessary keys, which need to be generated, distributed, and disposed of. Detailed recommendations for key management are provided in SP 800-57pt1r5 [20].
2455 2456 2457 2458 2459 2460
ENKM-KM-C01 – Protect keys used to encrypt storage: The use of all types of encryption for storage relies on the management of cryptographic keys. Poor key management can easily compromise data, no matter how strong the encryption is. Ultimately, the security of data protected by cryptography directly depends on the strength of the keys, the effectiveness of the mechanisms and protocols associated with the keys, and the protection afforded to the keys. For storage, the following are of particular importance:
2461
(a) All keys should be protected against modification.
2462 2463
(b) Secret (for symmetric encryption) and private (for asymmetric or public key encryption) keys should be protected against unauthorized disclosure.
2464 2465
(c) Foundational key management (e.g., secure generation, storage, distribution and destruction of keys) should conform to overall frameworks for key management [20].
2466 2467
ENKM-KM-C02 – Recommendations for encryption key management: The following recommendations [20] for key management should be followed:
2468 2469 2470 2471 2472 2473
(a) Limit key use to finite cryptoperiod or maximum amount of data processed: Symmetric data encryption keys used to protect the confidentiality of sensitive data should be limited to a finite cryptoperiod (typically no more than 2 years) or to a maximum amount of data processed [20]. An example of the latter case is XTS-AES [35], which limits the amount of data protected by a single key to no more than 256 TiB of data.
2474 2475 2476
(b) Use cryptographic keys for one purpose: Cryptographic keys should only be used for one purpose. For example, key-encrypting keys (i.e., key-wrapping keys) should not be used to encrypt data.
66
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2477 2478 2479
(c) Randomly generate keys using the entire keyspace: Keys should be randomly generated from the entire keyspace. Key generation should follow the SP 800-90A [37] specification.
2480 2481
(d) Limit exposure of plaintext keys: The amount of time a key is in plaintext form should be limited, and users should be prevented from viewing plaintext keys.
2482 2483 2484 2485 2486 2487
(e) Plan for key failures: The loss or corruption of encryption keys can render data unusable, so organizations should protect their encryption keys (e.g., a key backup of a key management server) and have key-recovery plans and mechanisms in place. Key backup is often implemented in the context of a specific encryption/key management solution and is focused on providing the solution access to the keys used to encrypt data within the solution.
2488 2489
ENKM-KM-C03 – KM compatible with data retention and preservation: Encryption and key management solutions should be compatible with data retention and preservation obligations.
2490 2491 2492 2493 2494
ENKM-KM-C04 – Use centralized key management: When possible, storage systems and infrastructure should use interoperable, centralized key management infrastructure. The Organization for the Advancement of Structured Information Standards (OASIS) Key Management Interoperability Protocol (KMIP) specification and profiles define the dominant mechanism for accessing centralized key management within storage infrastructures.
2495
4.7. Storage Disposal and Reuse (SDRU)
2496 2497
SDRU-GN-C01 – Storage disposal considerations: When storage systems or media are no longer needed, the organization should identify and document:
2498
•
The sensitivity and value of data previously stored on the system or media
2499
•
The reuse potential of the system or media
2500 2501
•
The proposed disposal approach for reuse (e.g., transfer, sale, donation) or elimination (e.g., recycling of components, discarding, destruction)
2502 2503 2504 2505
SDRU-GN-C02 – Secure disposal of storage: Storage systems/media that contain sensitive or high-value data should be handled as part of a storage sanitization program based on SP 800-88 [11] and using the sanitization techniques specified in IEEE Std 2883 [33] and NSA Policy Manual 9-12 [34]prior to disposal.
2506 2507 2508 2509 2510
SDRU-GN-C03 – Third-party collection and disposal services: Many third-party entities offer collection and disposal services for storage media. Care should be exercised when selecting and using a suitable external party supplier with adequate controls, experience, and certifications. For certain types of data, an organization’s loss of control of the storage system/media without sanitization can constitute a data breach.
2511 2512 2513
SDRU-GN-C04 – Accumulation of storage for disposal: The accumulation of non-sanitized storage systems and media for later disposal should be carefully handled because the aggregation effect can cause a large quantity of storage device/media with:
67
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2514
•
Non-sensitive information to become sensitive
2515
•
Sensitive information to become a high-value target for adversaries
68
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2516
5. Summary and Conclusions
2517 2518 2519 2520 2521
Along with compute (e.g., operating systems, host hardware) and network infrastructures, storage infrastructure is one of the three fundamental pillars of IT. However, compared to its counterparts, it has received relatively limited attention when it comes to security, even though data compromise can have as much of a negative impact on an enterprise as security breaches in compute and network infrastructures.
2522 2523 2524 2525
This document provided an overview of the storage technology landscape and discussed the threats and resulting risks to the safe utilization of storage resources. It also provided detailed security recommendations for the secure deployment, configuration, and operation of storage resources in various security focus areas, including:
2526 2527 2528
•
Areas that are common to all IT infrastructures, such as physical security, authentication and authorization, audit logging, network configuration, change management, incidence response and recovery, administrative access, and configuration management
2529 2530
•
Areas that are specific to storage infrastructures, such as data protection and confidentiality protection using encryption, isolation, and restoration assurance
2531 2532 2533 2534
Building an effective risk management program for storage infrastructure based on the security controls described in this document and tightly integrating it with existing cybersecurity frameworks [20] could significantly improve an organization’s resilience to attacks on data resources.
2535 2536 2537 2538 2539
It must be mentioned that modern storage infrastructures that support AI/ML workloads face the same type of threats and risks as ones supporting traditional programs, though at a higher scale and velocity. Hence the same mitigating controls such as Isolation, Encryption and Restoration Assurance that we have outlined in this document apply for storage infrastructures associated with those types of systems.
69
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
2540
References
2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581
[1] [2] [3] [4] [5] [6]
[7] [8] [9] [10] [11] [12] [13]
[14]
Security Guidelines for Storage Infrastructure
SNIA Online Dictionary as of April 2026. Available at https://www.snia.org/resources/online-dictionary Black D, Koning P, (2014) Remote Direct Memory Access Protocol. (Internet Engineering Task Force (IETF) Network Working Group), IETF Request for Comments (RFC) 7146. https://tools.ietf.org/html/rfc7146 Infinibandta.org (2020) InfiniBand Architecture Specification. Available at https://www.infinibandta.org/ibta-specification/ Haynes T (2016) Network File System (NFS) Version 4 Minor Version 2 Protocol. (Internet Engineering Task Force (IETF) Network Working Group), IETF Request for Comments (RFC) 7862. https://tools.ietf.org/html/rfc7862 Black D, Glasgow J, Faibish S (2012) Parallel NFS (pNFS) Block Disk Protection. (Internet Engineering Task Force (IETF) Network Working Group), IETF Request for Comments (RFC) 6688. https://tools.ietf.org/html/rfc6688 International Organization for Standardization/International Electrotechnical Commission (2024) ISO/IEC 27040 – Information technology — Security techniques — Storage security (ISO, Geneva, Switzerland). Available at https://www.iso.org/standard/80194.html Trust Radius (2020) Cloud Storage Systems. Available at https://www.trustradius.com/categories/cloud-storage Galibus T, Krasnoproshin VV, De Oliveira Albuquerque R, Pignaton de Freitas E (2016) Elements of Cloud Storage Security (Springer Nature, Switzerland AG) SNIA Storage Security: Data Protection Available at https://www.snia.org/sites/default/files/security/SNIA-Data-ProtectionTechWhitepaper.pdf Joint Task Force (2020) Security and Privacy Controls for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-53r5. https://doi.org/10.6028/NIST.SP.800-53r5 Chandramouli R, Hibbard E (2025) Guidelines for Media Sanitization. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-88r2. https://doi.org/10.6028/NIST.SP.800-88r2 Kass H (2019) Ransomware Attacks Target Backups, NAS (Network Attached Storage). MSSPAlert. Available at https://www.msspalert.com/cybersecurity-news/attacks-targetnas-backups/ Ross R, Pillitteri V (2024) Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-171r3. https://doi.org/10.6028/NIST.SP.800-171r3 Temoshok D, Abruzzi C, Choong Y, Fenton J, Galluzzo R, LaSalle C, Lefkovitz N, Regenscheid A, Vachino M (2025) Digital Identity Guidelines: Identity Proofing and Enrollment. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-63A-4. https://doi.org/10.6028/NIST.SP.800-63A-4
70
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624
[15]
[16]
[17] [18] [19] [20] [21] [22]
[23]
[24] [25] [26] [27]
Security Guidelines for Storage Infrastructure
Temoshok D, Fenton J, Choong Y, Lefkovitz N, Regenscheid A, Galluzzo R, Richer J (2025) Digital Identity Guidelines: Authentication and Authenticator Management. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-63B-4. https://doi.org/10.6028/NIST.SP.800-63B-4 McKay K, Cooper D (2019) Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-52r2. https://doi.org/10.6028/NIST.SP.800-52r2 SNIA (2020) TLS Specification for Storage Systems Version 2.2. Available at https://www.snia.org/sites/default/files/technical-work/tls/release/SNIA-TLSSpecification-v2.2.pdf Department of Homeland Security (2017) Reducing the Risk of SNMP Abuse. Available at https://us-cert.cisa.gov/ncas/alerts/TA17-156A National Institute of Standards and Technology (2018) Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1. (National Institute of Standards and Technology, Gaithersburg, MD). https://doi.org/10.6028/NIST.CSWP.04162018 Barker E (2020) Recommendation for Key Management: Part 1 – General. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-57pt1r5. https://doi.org/10.6028/NIST.SP.800-57pt1r5 Joint Task Force (2012) Guide for Conducting Risk Assessments. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-30r1. https://doi.org/10.6028/NIST.SP.800-30r1 Joint Task Force (2011) Managing Information Security Risk: Organization, Mission, and Information System View. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-39. https://doi.org/10.6028/NIST.SP.800-39 International Organization for Standardization/International Electrotechnical Commission (2022) ISO/IEC 27005 – Information security, cybersecurity and privacy protection — Guidance on managing information security risks (ISO, Geneva, Switzerland). Available at https://www.iso.org/standard/80585.html Regenscheid A (2018) Platform Firmware Resiliency Guidelines (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-193. https://doi.org/10.6028/NIST.SP.800-193 Ross R, Winstead M, McEvilley M (2022) Engineering Trustworthy Secure Systems (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-160v1r1. https://doi.org/10.6028/NIST.SP.800-160v1r1 Hild D, McEvilley M, Winstead M (2021) Principles for Trustworthy Design of Cyber Physical Systems. MITRE Technical Report, MTR210263. https://apps.dtic.mil/sti/trecms/pdf/AD1146447.pdf International Organization for Standardization/International Electrotechnical Commission/Institute of Electrical and Electronics Engineers (2015) ISO/IEC/IEEE 15288:2015 – Systems and software engineering – Systems life cycle processes. https://www.iso.org/standard/63711.html
71
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659
[28] [29]
[30]
[31]
[32]
[33] [34]
[35] [36] [37]
Security Guidelines for Storage Infrastructure
DMTF DSP0274, Security Protocol and Data Model (SPDM) Specification 1.4, available at https://www.dmtf.org/standards/spdm Cooper D, Polk W, Regenscheid A, Souppaya M (2011) BIOS Protection Guidelines: Recommendations of the National Institute of Standards and Technology (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-147. https://doi.org/10.6028/NIST.SP.800-147 Temoshok D, Abruzzi C, Choong Y, Fenton J, Galluzzo R, LaSalle C, Lefkovitz N, Regenscheid A, Vachino M (2025) Digital Identity Guidelines: Identity Proofing and Enrollment, (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-63A-4, https://doi.org/10.6028/NIST.SP.800-63A-4 International Organization for Standardization/International Electrotechnical Commission (2026) ISO/IEC 15408-series, Information security, cybersecurity and privacy protection — Evaluation criteria for IT security (ISO, Geneva, Switzerland). Available at https://www.iso.org/standard/15408-1 National Institute of Standards and Technology (2019) Security Requirements for Cryptographic Modules. (Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) NIST FIPS 140-3. https://doi.org/10.6028/NIST.FIPS.140-3 IEEE Standards Association, IEEE Std 2883 – IEEE Standard for Sanitizing Storage (IEEE Standards Association, Piscataway, New Jersey). Available at https://standards.ieee.org/ieee/2883/10277/ National Security Agency/Central Security Service (2020) NSA/CSS Storage Device Sanitization and Destruction Manual. NSA/CSS Policy Manual 9-12, December 4, 2020. Available at https://www.nsa.gov/Helpful-Links/NSA-FOIA/DeclassificationTransparency-Initiatives/NSA-CSS-Policies/ IEEE Standards Association, IEEE Std 1619-2025 – IEEE Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices (IEEE Standards Association, Piscataway, New Jersey). Available at https://standards.ieee.org/ieee/1619/11552/ IEEE Standards Association, IEEE Std 1619.1-2018 – IEEE Standard for Authenticated Encryption with Length Expansion for Storage Devices (IEEE Standards Association, Piscataway, New Jersey). Available at https://standards.ieee.org/ieee/1619.1/7153/ Barker E, Kelsey J (2015) Recommendation for Random Number Generation Using Deterministic Random Bit Generators. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-90A Revision 1. https://doi.org/10.6028/NIST.SP.800-90Ar1
72
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2660
Appendix A. List of Symbols, Abbreviations, and Acronyms
2661
Selected acronyms and abbreviations used in the document are defined below.
2662 2663
ACL Access Control List
2664 2665
API Application Programming Interface
2666 2667
BC Business Continuity
2668 2669
BCM Business Continuity Management
2670 2671
BIOS Basic Input/Output System
2672 2673
CDN Content Delivery Networks
2674 2675
CHAP Challenge-Handshake Authentication Protocol
2676 2677
CIFS Common Internet File System
2678 2679
CISO Chief Information Security Officer
2680 2681
CLI Command Line Interface
2682 2683
CPU Central Processing Unit
2684 2685
CSO Chief Security Officer (interchangeable with CISO)
2686 2687
CSI Container Storage Interface
2688 2689
CTO Chief Technology Officer
2690 2691
DAS Directly Attached Storage
2692 2693
DDoS Distributed Denial of Service
2694 2695
DMA Direct Memory Access
2696 2697
DoS Denial of Service
73
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
2698 2699
DR Disaster Recovery
2700 2701
FC Fibre Channel
2702 2703
FCIP Fibre Channel over IP
2704 2705
FIPS Federal Information Processing Standards
2706 2707
GNS Global Name Server
2708 2709
FTP File Transfer Protocol
2710 2711
GPS Global Positioning System
2712 2713
HBA Host Bus Adapter
2714 2715
HDD Hard Disk Drives
2716 2717
HIPAA Health Insurance Portability and Accountability Act
2718 2719
HPC High-Performance Computing
2720 2721
HTTP HyperText Transfer Protocol
2722 2723
HTTPS HyperText Transfer Protocol Secure
2724 2725
I/O input/output
2726 2727
IP Internet Protocol
2728 2729
IS Information Security
2730 2731
iSCSI Internet Small Computer Systems Interface
2732 2733
ISL Inter Switch Link
2734 2735
iSNS Internet Storage Name Service
Security Guidelines for Storage Infrastructure
74
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
2736 2737
IT Information Technology
2738 2739
KPI Key Performance Indicator
2740 2741
LAN Local Area Network
2742 2743
LDAP Lightweight Directory Access Protocol
2744 2745
LUN Logical Unit Number
2746 2747
LVM Logical Volume Manager
2748 2749
MAC Message Authentication Codes
2750 2751
MFA Multi-Factor Authentication
2752 2753
NAS Network-Attached Storage
2754 2755
NDMP Network Data Management Protocol
2756 2757
NFS Network File System
2758 2759
NIC Network Interface Card
2760 2761
NS Name Server
2762 2763
NTP Network Time Protocol
2764 2765
NVM Non-Volatile Memory
2766 2767
NVMe Non-Volatile Memory express
2768 2769
NVMe-oF NVMe over fabrics
2770 2771
OS Operating System
2772 2773
OSI Open Systems Interconnection
Security Guidelines for Storage Infrastructure
75
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2774 2775
PBKDF2 Password-Based Key Derivation Function 2
2776 2777
PCI Payment Card Industry; Peripheral Component Interconnect
2778 2779
PCIe PCI express
2780 2781
PCI-DSS Payment Card Industry Digital Security Standard
2782 2783
PII Personally Identifiable Information
2784 2785
PKI Public-Key Infrastructure
2786 2787
pNFS Parallel NFS
2788 2789
QA Quality Assurance
2790 2791
QoS Quality of Service
2792 2793
RDMA Remote Direct Memory Access
2794 2795
RFID Radio-Frequency Identification
2796 2797
RPO Recovery Point Objective
2798 2799
RSH Remote Shell
2800 2801
RTO Recovery Time Objective
2802 2803
SAN Storage Area Network
2804 2805
SCSI Small Computer System Interface
2806 2807
SHA Secure Hash Algorithm
2808 2809
SIEM Security Information and Event Management
2810 2811
SMB Server Message Block
76
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
2812 2813
SMI-S Storage Management Initiative Specification
2814 2815
SNMP Simple Network Management Protocol
2816 2817
SNS Simple Name Server
2818 2819
SoC System on Chip
2820 2821
SPKM Simple Public-Key GSS-API Mechanism
2822 2823
SRP Server Routing Protocol
2824 2825
SSD Solid-State Drive
2826 2827
SSH Secure SHell
2828 2829
SSO Single Sign-On
2830 2831
TCP Transmission Control Protocol
2832 2833
TLS Transport Layer Security
2834 2835
UDP User Datagram Protocol
2836 2837
UI User Interface
2838 2839
USB Universal Serial Bus
2840 2841
VLAN Virtual LAN
2842 2843
VM Virtual Machine
2844 2845
VPC Virtual Private Cloud
2846 2847
VPN Virtual Private Network
2848 2849
WAN Wide-Area Network
Security Guidelines for Storage Infrastructure
77
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
2850 2851
WORM Write Once Read Many
2852 2853
WWN World Wide Name
2854 2855
WWPN World Wide Port Name
2856 2857
XML eXtensible Markup Language
Security Guidelines for Storage Infrastructure
78
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2858
Appendix B. Glossary
2859 2860
block A unit in which data is stored and retrieved on storage media. [1]
2861 2862
block storage A method of storing data in blocks. [1]
2863 2864
Fibre Channel A serial I/O interconnect capable of supporting multiple protocols. [1]
2865 2866 2867
incident Anomalous or unexpected event, set of events, condition, or situation at any time during the life cycle of a project, product, service, or system. [27]
2868 2869
Input/output The process of moving data between a computer system's main memory and an external device or interface. [1]
2870 2871 2872
Internet Small Computer Systems Interface A transport protocol that provides for the SCSI protocol to be carried over a TCP based IP network, standardized by the Internet Engineering Task Force and described in RFCs 791, 1122, 2003, and 3720. [1]
2873 2874
network-attached storage A storage device that connects to a network and provides file access services to clients. [1]
2875 2876 2877
point in time copy A fully usable copy of a defined collection of data that contains an image of the data as it appeared at a single instant in time. [1]
2878 2879 2880
A point in time copy is considered to have logically occurred at that point in time, but implementations may perform part or all of the copy at other times (e.g., via database log replay or rollback) as long as the result is a consistent copy of the data as it appeared at that point in time.
2881 2882 2883
point of encryption Location within the Information and Communications Technology (ICT) infrastructure where data are encrypted on its way to storage (3.43) and, conversely, where data are decrypted when accessed from storage. [6]
2884 2885
recovery The recreation of a past operational state of an entire application or computing environment. [1]
2886 2887 2888
Recovery point objective The maximum acceptable time period prior to a failure or disaster during which changes to data may be lost as a consequence of recovery. [1]
2889 2890 2891
Recovery time objective The maximum acceptable time period required to bring one or more applications and associated data back from an outage to a correct operational state. [1]
2892 2893
security domain A domain that implements a security policy and is administered by a single authority. [13]
2894 2895
snapshot A point in time copy of a defined collection of data. [1]
2896 2897
Clones and snapshots are full copies. Depending on the system, snapshots may be of files, LUNs, file systems, or any other type of container supported by the system.
79
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2898 2899
storage area network A serial I/O interconnect capable of supporting multiple protocols. [1]
2900 2901
storage virtualization The application of virtualization to storage services or devices. [1]
2902 2903
trust A belief that an entity meets certain expectations and, therefore, can be relied upon. [26]
2904 2905 2906 2907 2908 2909 2910
Note: The term belief implies that trust may be granted to an entity whether the entity is trustworthy or not. trust relationship An agreed-upon relationship between two or more system elements that is governed by criteria for secure interaction, behavior, and outcomes relative to the protection of assets. [25] Note: This refers to trust relationships between system elements implemented by hardware, firmware, and software.
2911 2912
vulnerability A weakness that can be exploited or triggered to produce an adverse effect.
2913
The inability to withstand adversity. [25]
2914 2915
Note: Vulnerability can exist anywhere throughout the life cycle of a system, such as in the CONOPS, procedures, processes, requirements, design, implementation, utilization, and sustainment of the system.
2916
80
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2917
Appendix C. Controls List and Mapping of Mitigating Controls to Storage-Oriented Threats
2918
This appendix consists of two tables:
2919 2920
•
Table 1 provides a comprehensive list of all mitigating controls provided in this document, including their labels and titles.
2921 2922
•
Table 2 provides a mapping of the relevant controls in this document to the storageoriented threats identified in Sec. 3.1.
2923
Not all the controls are listed in the following table as some are related to generic ICT threats.
2924
Table 1. Comprehensive list of control labels and titles Control Label Control Description Data Storage Governance (DSGV) (4.1) DSGV-PP-C01 Comprehensive storage security policy DSGV-PP-C02 Keep the storage security policy current DSGV-PP-C03 Compliance with storage security policy DSGV-PP-C04 Data protection plan or policy DSGV-PP-C05 Completeness of data protection plan or policy DSGV-PP-C06 Backup plan or policy DSGV-PP-C07 Ensure the completeness of recovery copies DSGV-PP-C08 Protect all dependent ICT components DSGV-PP-C09 Document the DR plan, resources, mapping to production, flow, and test procedures DSGV-PP-C10 Storage consideration for policy DSGV-PP-C11 Include storage infrastructure in logging and monitoring policy DSGV-DT-C01 Include storage in BCM planning/testing DSGV-DT-C02 Document data retention and sanitization obligations DSGV-DT-C03 Document and verify storage compliance with privacy obligations DSGV-DT-C04 Document and verify storage compliance with legal obligations DSGV-SR-C01 Create a comprehensive inventory of all storage devices DSGV-SR-C02 Create a comprehensive inventory of all data and configuration assets DSGV-SR-C03 Network topology documentation DSGV-SR-C04 Detect unauthorized storage security changes DSGV-SR-C05 Develop a response plan for storage component compromise DSGV-SR-C06 Develop a change management process for storage DSGV-SR-C07 Perform periodic isolation reviews DSGV-SR-C08 Set RPO and RTO DSGV-SR-C09 Meeting organizational frequency and retention objectives DSGV-PC-C01 Storage security training DSGV-PC-C02 Ensuring adequate storage data protection expertise DSGV-PC-C03 Ensuring adequate storage security expertise Physical Controls for Data Storage (PSDS) (4.2) PSDS-PS-C01 Physically securing storage media PSDS-PS-C02 Physically securing storage devices PSDS-PS-C03 Use media security measures PSDS-PS-C04 Protect all sensitive administrative equipment PSDS-PS-C05 Use of storage sanitization PSDS-PS-C06 Use of immutable storage PSDS-PI-C01 Protect physical management interfaces to storage PSDS-PI-C02 Protect physical SAN interfaces
81
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
Control Label Control Description PSDS-IS-C01 Separation of storage systems PSDS-IS-C02 Separation of management systems PSDS-IS-C03 Isolation of storage systems PSDS-IS-C04 Logically isolating storage systems Storage Systems Security (DSSS) (4.3) DSSS-GN-C01 Defense in depth for storage DSSS-GN-C02 Establish security domains for storage DSSS-GN-C03 Align storage security domains with purpose DSSS-SH-C01 Perform basic operating system hardening DSSS-SH-C02 Use software updates and patches from trusted sources DSSS-SH-C03 Limit network access to management ports of SAN switches DSSS-SH-C04 Limit storage administrative capabilities DSSS-SH-C05 Favor API access control over CLI/shell access DSSS-SH-C06 Restrict management consoles OS privileges DSSS-SH-C07 Management web user interface DSSS-SH-C08 Secure storage management interfaces DSSS-SH-C09 Secure the remote management DSSS-SH-C10 Restrict vendor maintenance interfaces DSSS-SH-C11 Restrict vendor maintenance communications DSSS-SH-C12 Restrict vendor dial-up maintenance DSSS-SH-C13 Secure Intelligent Platform Management Interface (IPMI) DSSS-SH-C14 Restrict host storage control privileges DSSS-SH-C15 Command device or gatekeeper configuration DSSS-SH-C16 Disable or limit call home or remote access DSSS-SH-C17 Access control for management networks DSSS-SH-C18 Secure and protect core storage management files and binaries DSSS-SH-C19 Use an approved PKI mechanism for management access DSSS-SH-C20 Perform regular security audits of data DSSS-SH-C21 Disallow cleartext protocols DSSS-SH-C22 Encryption for storage management API sessions DSSS-SH-C23 Encryption for administrative access sessions DSSS-SH-C24 Enable FIPS mode for FIPS-based environments DSSS-SA-C01 Configure and use logging on storage infrastructure DSSS-SA-C02 Ensure completeness of storage logging DSSS-SA-C03 Monitor storage infrastructure DSSS-SA-C04 Protect and retain storage logs DSSS-SA-C05 Enable audit logging DSSS-SA-C06 Reliable, external time synchronization DSSS-SA-C07 Collect logs in a centralized fashion DSSS-SA-C08 Auding logging level DSSS-SA-C09 Audit log retention and protection DSSS-SA-C10 SIEM integration DSSS-VM-C01 Include storage infrastructure in vulnerability management programs DSSS-VM-C02 Software updates and patches DSSS-VM-C03 Scan files containing sensitive information with anti-malware tools on-access DSSS-AM-C01 Unique Identifier for all users DSSS-AM-C02 Use centralized authentication solution DSSS-AM-C03 Configuration of authentication servers DSSS-AM-C04 Secure connection to centralized authentication server
82
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
Control Label DSSS-AM-C05 DSSS-AM-C06 DSSS-AM-C07 DSSS-AM-C08 DSSS-AM-C09 DSSS-AM-C10 DSSS-AM-C11 DSSS-AM-C12 DSSS-AM-C13 DSSS-AM-C14 DSSS-AM-C15 DSSS-AM-C16 DSSS-AM-C17 DSSS-AM-C18 DSSS-AM-C19 DSSS-AM-C20 DSSS-AM-C21 DSSS-PR-C01 DSSS-PR-C02 DSSS-PR-C03
Control Description Use of multi-factor authentication Entity authentication Secure password policies should cover service accounts Use of accounts not associated with system users Account lockout A local user account for emergency purposes Eliminate or disable default user accounts Limit local and default user accounts Roles and responsibilities configuration Separation of duties The privileges assigned to any role should adhere to the principle of “least privilege” Secure Session Management Implement a “message of the day” and “login banner” notice Separate Security and Non-security Roles Implement the principle of least-privilege Limit the access rights of service accounts Authenticate and authorize all CLI/API access SNMP security Control of IP addresses used for SNMP The authenticity of directory, domain, and similar services (e.g., AD, Domain Name System (DNS), LDAP) DSSS-PR-C04 Considerations for using standard and non-standard TCP/IP or UDP ports DSSS-PR-C05 Use of Network Data Management Protocol (NDMP) security features DSSS-PR-C06 Use TLS in LDAP DSSS-PR-C07 Additional protocols DSSS-PR-C08 Use of TLS for encrypted communications DSSS-PS-C01 Support for secure initialization DSSS-PS-C02 Protection of system secrets DSSS-PS-C03 Securing system BIOS DSSS-PS-C04 Protection and update of firmware code DSSS-PS-C05 Disable debugging ports DSSS-PS-C06 Sensitive information in telemetry/debugging logs DSSS-PS-C07 Enhance trustworthiness with attestation DSSS-PS-C08 Anatomy of a trusted attester DSSS-PS-C09 Use SPDM for storage attestation Data Protection and Recovery (DPRC) (4.4) DPRC-GN-C01 Data protection configuration management DPRC-GN-C02 Design Data Protection for Recovery DPRC-SB-C01 The availability of all relevant software and hardware components DPRC-SB-C02 The elected backup and data copies technologies and media should match organizational RTO DPRC-SB-C03 Test restore to ensure RTO DPRC-SB-C04 Validate health of backup copies DPRC-SB-C05 Enable the separate restoration of data and application DPRC-SB-C06 Use data backup measures and operations securely DPRC-RM-C01 Synchronous and asynchronous replication DPRC-RM-C02 Eliminate unnecessary replication trust between storage devices DPRC-RM-C03 Secure replication/mirroring traffic DPRC-RM-C04 Automated I/O suspension DPRC-RM-C05 Eliminate obsolete replicas 83
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
Control Label Control Description DPRC-SS-C01 Configure point-in-time copies DPRC-SS-C02 Eliminate obsolete snapshots/clones DPRC-SS-C03 Snapshot security DPRC-CR-C01 Disable all unnecessary services and protocols DPRC-CR-C02 Recovery assets immutability during incident management DPRC-CR-C03 Validate the hygiene of recovered compute components DPRC-CR-C04 Access restriction to cyber-attack recovery system DPRC-CR-C05 Off-site storage DPRC-CR-C06 Use of an independent, full baseline copy DPRC-CR-C07 Independence from hosts and applications DPRC-CR-C08 Consider setting up an air gap DPRC-CR-C09 Cyber hygiene of data copies DPRC-CR-C10 Perform periodic audits DPRC-CR-C11 Secure cyber-attack recovery backups Storage Networking and Technologies (SNTC) (4.5) SNTC-BK-C01 Block-device access control SNTC-BK-C02 Block-device copy and replica access control SNTC-BK-C03 Use zoning is SAN-switched fabrics SNTC-BK-C04 Software zoning implementation SNTC-BK-C05 Controlling devices that can join fabric SNTC-BK-C06 FC host and switch authentication SNTC-BK-C07 The use of an approved FC PKI mechanism SNTC-BK-C08 Use Fibre Channel zoning SNTC-BK-C09 A blended approach to FC zoning SNTC-BK-C10 FC masking Recommendation SNTC-BK-C11 A backup of FC switch configuration data SNTC-BK-C12 Limit FC switch management capabilities to the minimum necessary SNTC-BK-C13 Limit communication between FC switches SNTC-BK-C14 Disable unused FC SAN ports SNTC-BK-C15 Audit FC SAN security configuration SNTC-BK-C16 Confidentiality protections for Fibre Channel storage SNTC-BK-C17 Sanitization for Fibre Channel-based storage SNTC-BK-C18 Use NVMe-oF authentication SNTC-BK-C19 Use NVMe/FC Security SNTC-BK-C20 Segregate iSCSI networks SNTC-BK-C21 Secure iSCSI networks SNTC-BK-C22 Secure FCIP networks SNTC-BK-C23 Secure NVMe/RDMA networks SNTC-BK-C24 Confidentiality protections for IP storage SNTC-BK-C25 Sanitization for IP-based storage SNTC-BK-C26 IP storage network separation SNTC-BK-C27 Isolate IP/Ethernet management ports SNTC-BK-C28 Enable device IP access control SNTC-BK-C29 Enable network IP access control SNTC-BK-C30 Limit iSCSI ports SNTC-BK-C31 Use iSCSI authentication SNTC-BK-C32 Use NVMe/TCP Security SNTC-FL-C01 NFS network access and protocols SNTC-FL-C02 Apply NFS authentication
84
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
Control Label SNTC-FL-C03 SNTC-FL-C04 SNTC-FL-C05 SNTC-FL-C06 SNTC-FL-C07 SNTC-FL-C08 SNTC-FL-C09 SNTC-FL-C10 SNTC-FL-C11 SNTC-FL-C12 SNTC-FL-C13 SNTC-FL-C14 SNTC-OB-C01 SNTC-OB-C02 SNTC-OB-C03 SNTC-OB-C04
Control Description Apply NFS access controls Secure NFS client access Secure data on NFS servers Secure NFS by restricting root access NFS “read only” mode NFS export of administrative file systems should not be allowed Disable NFS non-authenticated access Apply SMB networking controls Apply SMB access controls Secure data on SMB servers Disable insecure versions of SMB Restrict SMB “full control” permissions Permission for default zone Non-public storage objects Public access Restricting access to object storage data of all types (e.g., Files, Objects) to the minimum possible SNTC-OB-C05 Use object protection to prevent unauthorized deletion SNTC-OB-C06 Secure transfer of objects SNTC-OB-C07 Confidentiality protections for stored objects SNTC-OB-C08 Sanitization for object-based storage Encryption and Key Management (ENKM) (4.6) ENKM-GN-C01 Use encryption to protect sensitive, regulated, and high-value data ENKM-GN-C02 Storage encryption provides limited confidentiality protection ENKM-GN-C03 Use encryption to protect administrative/management control of storage ENKM-GN-C04 Limiting operational impacts of cryptography ENKM-GN-C05 Security Strength of Cryptography ENKM-GN-C06 Use Validated Cryptographic Modules ENKM-GN-C07 Complying with import/export regulation for cryptography ENKM-GN-C01 Complying with import/export regulation for cryptography ENKM-EN-C01 At-rest encryption of sensitive data ENKM-EN-C02 Using an appropriate point of encryption ENKM-EN-C03 Creating appropriate proof of encryption ENKM-EN-C04 Using data reduction technologies with encryption ENKM-ET-C01 Use of end-to-end encryption ENKM-ET-C02 Data in transit encryption ENKM-ET-C03 Communication between storage system components should be encrypted ENKM-KM-C01 Protect keys used to encrypt storage ENKM-KM-C02 Recommendations for Encryption key management ENKM-KM-C03 KM compatible with data retention and preservation ENKM-KM-C04 Use centralized key management Storage Disposal and Reuse (SDRU) (4.7) SDRU-GN-C01 Storage disposal considerations SDRU-GN-C02 Secure disposal of storage SDRU-GN-C03 Third-party collection and disposal services SDRU-GN-C04 Accumulation of storage for disposal
2925 2926
85
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
2927
Table 2. Mapping of storage-oriented threats to mitigating controls Storage-Oriented Threats Infection of Malware and Ransomware (Sec. 3.1.1)
Unpatched Vulnerabilities (Sec. 3.1.2)
Physical Theft or Inappropriate Disposal of Storage Media (Sec. 3.1.3)
2928
Security Guidelines for Storage Infrastructure
Platform Security Compromises (Sec. 3.1.4)
Mitigating Controls (4.1.1) DSGV-PP-C04 Data protection plan or policy (4.1.1) DSGV-PP-C05 Completeness of data protection plan or policy (4.1.1) DSGV-PP-C06 Backup plan or policy (4.1.1) DSGV-PP-C07 Ensure the completeness of recovery copies (4.1.1) DSGV-PP-C09 Document the DR plan, resources, mapping to production, flow, and test procedures (4.1.3) DSGV-SR-C04 Detect unauthorized storage security changes (4.1.3) DSGV-SR-C05 Develop a response plan for storage component compromise (4.2.3) PSDS-IS-C01 Separation of storage systems (4.2.3) PCDS-IS-C03 Isolation of storage systems (4.2.3) PCDS-IS-C04 Logically isolating storage systems (4.3.2) DSSS-SA-C01 Configure and use logging on storage infrastructure (4.3.2) DSSS-SA-C03 Monitor storage infrastructure (4.3.3) DSSS-VM-C03 Scan files containing sensitive information with antimalware tools on-access (4.4.1) DPRC-SB-C06 Use data backup measures and operations securely (4.4.4) DPRC-CR-C08 Consider setting up an air gap (4.4.4) DPRC-CR-C11 Secure cyber-attack recovery backups (4.3.1) DSSS-SH-C01 Perform basic operating system hardening (4.3.1) DSSS-SH-C02 Establish security domains for storage (4.3.2) DSSS-SA-C01 Ensure completeness of storage logging (4.3.2) DSSS-SA-C03 Monitor storage infrastructure (4.3.3) DSSS-VM-C01 Include storage infrastructure in vulnerability management programs (4.3.3) DSSS-VM-C02 Software updates and patches (4.2.1) PSDS-PS-C01 Physically securing storage media (4.2.1) PSDS-PS-C02 Physically securing storage devices (4.2.1) PSDS-PS-C03 Use media security measures (4.2.1) PSDS-PS-C05 Use of storage sanitization (4.7) SDRU-GN-C01 Storage disposal considerations (4.7) SDRU-GN-C02 Secure disposal of storage (4.3.2) DSSS-SA-C01 Configure and use logging on storage infrastructure (4.3.2) DSSS-SA-C03 Monitor storage infrastructure
86
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2929
Appendix D. Change Log
2930
This document revises SP 800-209 (2020) as follows:
2931
Section 2: Data Storage Technologies Background
2932 2933 2934 2935
•
Content in Sec. 2 and elsewhere that was associated with obsolete and/or niche technologies (e.g., Fibre Channel over Ethernet, software defined storage, hyperconverged storage, continuous data protection) has been removed.
Section 3: Data Storage Technologies Background
2936 2937 2938
•
Section 3 was revised to primarily focus on the threats and risks that have particular relevance to storage systems and ecosystems. References to other NIST publication are provided for more generic ICT threats and risks.
2939 2940 2941
•
The phrase “attack surfaces" was removed from the title, and the associated subsection (Sec. 3.3) was removed. The removed attack surface descriptions were generic and duplicated content in other NIST publications.
2942 2943
•
Section 3.1.4, “Platform Security Compromises,” has been added to focus on threats associated with the underlying/supporting infrastructure for data storage.
2944 2945 2946
•
Section 3.2.4, “Compromised Data Resilience/Protection,” has been added to focus on threats to secondary data assets and the secondary data asset generation process (i.e., backups).
2947
Section 4: Data Storage Technologies Background
2948 2949 2950 2951
•
The title has been changed from “Security Guidelines for Storage Deployments” to “Storage Security Controls,” and the recommendations have been reorganized from nine categories into seven formalized control families with standardized control acronyms.
2952
•
The guidance in Sec. 4 has been restructured to improve readability.
2953 2954
•
Generic security controls (e.g., password-specific controls) were replaced with references to other NIST publications.
2955 2956
•
A new label scheme was applied to the controls in Sec. 4, and these new labels (and short descriptions) are leveraged in the new Appendix C.
2957 2958 2959
•
Section 4.1, “Data Storage Governance (DSGV),” has been added to address policy, planning, storage resource management, and people controls. It incorporates some of the configuration management concepts discussed in the original document.
2960 2961
•
Section 4.2, “Physical Controls for Data Storage (PSDS),” consolidates the two former sections on physical storage security and isolation.
2962 2963 2964 2965
•
Section 4.3, “Storage Systems Security (DSSS),” now encompasses storage system hardening, security auditing and monitoring, vulnerability management, and platform security. This effectively merges the former stand-alone sections on authentication and data access control, administrative access, and audit logging. 87
NIST SP 800-209r1 ipd (Initial Public Draft) July 2026
Security Guidelines for Storage Infrastructure
2966 2967
•
Section 4.4, “Data Protection and Recovery (DPRC),” replaces and merges the previous data protection and restoration assurance sections.
2968 2969 2970
•
Section 4.4.4, “Cyber Recovery Systems,” is a new subsection that addresses incident response measures under the umbrella of “cybersecurity program management” but focuses on storage infrastructure and data assets.
2971 2972 2973
•
Section 4.5, “Storage Networking and Technologies (SNTC),” categorizes security controls grouped by block-based, file-based, and object-based storage networking architectures.
2974 2975 2976
•
Section 4.6, “Encryption and Key Management (ENKM),” expands upon the original encryption section by adding controls related to key management and associated infrastructure.
2977 2978
•
Section 4.7, “Storage Disposal and Reuse (SDRU),” is entirely dedicated to the secure disposal and sanitization of storage media.
2979 2980
•
Appendix C was added to provide a complete list of storage security controls as well as a mapping of mitigating controls for the storage-oriented threats identified in Sec. 3.
88
Related documents
- NIST SP 800-111: Guide to Storage Encryption Technologies for End User Devices#2859
- NIST SP 800-123: Guide to General Server Security#2867
- NIST SP 800-214: 2020 Cybersecurity and Privacy Annual Report#2964
- NIST SP 800-83r1: Guide to Malware Incident Prevention and Handling for Desktops and Laptops#3048
- NIST SP 800-176: Computer Security Division 2014 Annual Report#2927
Retrieved via Conceptio: every document is proof-bundled with source, license, and retrieval metadata.
Read the Docs → · View CLI source on GitHub · Conceptio Open Knowledge Archive