SI-16: Memory Protection

Quick-reference card

What this control requires

SI-16 requires organizations to implement safeguards that prevent unauthorized code from executing in protected regions of system memory. In practice, this control means deploying technical mechanisms that enforce boundaries between executable and non-executable memory regions across every system in scope. The two primary mechanisms the control targets are data execution prevention (DEP) and address space layout randomization (ASLR). DEP marks certain memory regions as non-executable, stopping attackers from running injected shellcode in data segments like the stack or heap. ASLR randomizes the memory addresses where system components load, making it harder for exploits to predict where critical code and data structures reside. Without these protections, a single buffer overflow vulnerability can give an attacker full control of a system. SI-16 exists because memory-based attacks remain one of the most reliable paths from initial access to code execution. Organizations subject to NIST SP 800-53 moderate and high baselines must demonstrate that these safeguards are configured, enforced, and documented across their environment.

Why it matters

Memory protection failures introduce direct audit risk for organizations operating under NIST SP 800-53 moderate or high baselines. Assessors testing SI-16 look for verifiable evidence that DEP and ASLR are enabled and enforced across all in-scope systems. A gap here doesn’t require a breach to create consequences. It surfaces as a finding during authorization assessments, and unresolved findings can delay or block an authority to operate (ATO). The compliance exposure extends beyond a single control. SI-16 intersects with software integrity (SI-07), security function isolation (SC-03), and reference monitoring (AC-25). A deficiency in memory protection can cascade into findings across multiple control families, compounding the remediation burden and raising questions about the organization’s overall security posture. Failure to maintain this control introduces audit risk and may result in certification withdrawal or regulatory findings. For organizations pursuing or maintaining FedRAMP authorization, an unimplemented SI-16 creates a plan of action and milestones (POA&M) item that requires tracked remediation with defined timelines. Beyond compliance, unprotected memory is one of the most well-understood attack surfaces in computing. Threat actors routinely target systems lacking memory safeguards because exploitation techniques are mature, documented, and automatable.

What attackers exploit

• Buffer overflow attacks that inject malicious code into stack or heap memory regions and redirect execution flow to the injected payload
• Return-oriented programming (ROP) that chains together short instruction sequences from existing executable code to bypass non-executable memory protections without injecting new code
• Code injection into non-executable regions where attackers write shellcode to memory segments marked as data and then manipulate execution to run that code
• ASLR bypass through information leakage where vulnerabilities disclose memory layout information, allowing attackers to calculate the addresses of critical functions and defeat randomization
• Heap spraying that floods heap memory with attacker-controlled data to increase the probability that execution lands on a malicious payload

How to implement

Most SI-16 failures stem from inconsistent enforcement rather than missing capability. Modern operating systems ship with DEP and ASLR support built in, but misconfigurations, legacy application exceptions, and incomplete deployment across the system inventory leave gaps that assessors catch and attackers target.

For your organization

Start with a system-wide inventory to identify which operating systems, firmware versions, and applications are in scope for SI-16. Map each system’s current DEP and ASLR status before making configuration changes. Enable DEP at the operating system level. On Windows systems, configure DEP through the system’s exploit protection settings or via Group Policy. Set DEP to “OptOut” mode, which enforces protection for all processes except those with explicit exceptions. On Linux systems, verify that the NX (No-Execute) bit is enabled in the kernel and supported by the processor. Document any application-specific exceptions with a justification tied to operational need. Enable ASLR across all supported systems. On Windows, turn on bottom-up ASLR and mandatory ASLR through exploit protection policies. On Linux, confirm that kernel ASLR is active by checking the randomize_va_space kernel parameter. A value of 2 provides full randomization across stack, heap, and shared library regions. Configure firmware-level protections. Verify that BIOS or UEFI settings enable hardware-enforced DEP (the NX/XD bit). Hardware enforcement provides stronger protection than software-only approaches because it operates below the operating system and can’t be disabled by user-mode exploits. Deploy endpoint protection that monitors for memory exploitation. Endpoint detection and response (EDR) tools and exploit mitigation solutions can detect and block exploitation attempts that target memory regions, providing a defense layer beyond static configuration. Avoid common mistakes. Disabling DEP for compatibility with legacy applications without documenting the exception is one of the most frequent audit findings. Another is assuming that enabling DEP on workstations satisfies the control while leaving servers unprotected. Test all in-scope systems, not just a sample.

For your vendors

When assessing whether a vendor meets SI-16 requirements, generic attestations of “security best practices” aren’t sufficient. You need evidence that memory protection mechanisms are configured and enforced on the systems that process your data. Ask targeted questionnaire questions. Include questions such as: “Is data execution prevention enabled on all systems processing customer data?” and “What is your organization’s ASLR configuration policy across production environments?” Ask vendors to describe any exceptions to DEP enforcement and the justification for each exception. Request specific evidence. Ask for system configuration exports showing DEP and ASLR status, screenshots of exploit protection settings, or configuration management tool reports that confirm enforcement across the vendor’s environment. A system and information integrity policy document should explicitly address memory protection controls, not just reference them in passing. Watch for red flags. Vendors that can’t distinguish between DEP and ASLR, or that claim “the operating system handles it automatically” without showing configuration evidence, may not have deliberate memory protection controls in place. Vendors running legacy operating systems that don’t support ASLR or hardware-enforced DEP present elevated risk. Verify beyond self-attestation. Where possible, review independent assessment reports (such as SOC 2 Type II or FedRAMP authorization packages) for evidence that SI-16 was tested. If the vendor’s systems are within your assessment boundary, include memory protection verification in your own audit procedures. The NIST SP 800-53 framework expects organizations to validate that vendor-operated systems meet the same control requirements applied to internal systems.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for SI-16.

Related controls

• AC-25 — Reference Monitor: Defines the tamper-resistant mechanism that mediates all access to system resources. Memory protection supports the integrity of reference monitor components by preventing unauthorized code from executing in their address space.
• SC-03 — Security Function Isolation: Requires that security functions operate in isolated execution domains. Memory protection mechanisms like DEP and ASLR help enforce this isolation by preventing code injection across domain boundaries.
• SI-07 — Software, Firmware, and Information Integrity: Addresses detection of unauthorized changes to software and firmware. Memory protection complements integrity verification by preventing unauthorized code execution even when integrity checks haven’t yet detected a modification.

Frequently asked questions

What is NIST SP 800-53 SI-16?

SI-16 is the NIST SP 800-53 control that requires organizations to implement security safeguards protecting system memory from unauthorized code execution. It targets mechanisms like data execution prevention and address space layout randomization that stop attackers from running malicious code in protected memory regions. The control applies to moderate and high baselines and requires both configuration enforcement and documented evidence of deployment.

What happens if SI-16 is not implemented?

Failure to implement SI-16 results in a documented finding during security authorization assessments, which can delay or block an authority to operate. Without memory protection controls like DEP and ASLR, systems lack a foundational defense against buffer overflow and code injection attacks. Assessors evaluating the system and information integrity family treat an absent SI-16 as a significant gap that raises questions about the broader control environment.

How do you audit SI-16?

Auditing SI-16 requires reviewing system configuration settings to verify that data execution prevention and address space layout randomization are enabled and enforced across all in-scope systems. Assessors examine the list of security safeguards protecting system memory from unauthorized code execution and compare it against the system security plan. They also review audit records for DEP violation events, check for documented exceptions, and validate that firmware-level protections like the NX/XD bit are active in BIOS or UEFI settings.

What is the difference between hardware-enforced and software-enforced memory protection?

Hardware-enforced memory protection uses processor-level features like the NX (No-Execute) or XD (Execute Disable) bit to mark memory pages as non-executable at the hardware level. Software-enforced protection emulates this behavior through operating system mechanisms, but operates at a higher level where it can potentially be bypassed by kernel-level exploits. NIST guidance for SI-16 notes that hardware enforcement provides the greater strength of mechanism because it operates below the software layer and resists tampering by user-mode or kernel-mode attacks.