Aligning to the NIST Cybersecurity Framework in the AWS Cloud

Aligning to the NIST Cybersecurity Framework in the AWS Cloud means systematically mapping AWS-native services and your own controls to all six CSF 2.0 functions, deciding how much key control you retain, and collecting the evidence auditors actually require. Organizations that get this right reduce breach risk, simplify regulatory audits, and build a cloud security posture they can defend. The recommended starting point: use AWS Organizations and Control Tower to operationalize the new Govern function, then map each remaining function to the AWS services in the table below, and decide early whether native AWS KMS, BYOK, or HYOK key management fits your sovereignty and compliance requirements.

Quick Answer: How Do You Align AWS to NIST CSF 2.0?

NIST CSF 2.0 has six core functions: Govern, Identify, Protect, Detect, Respond, and Recover. In AWS, you satisfy these functions by deploying the right native services for each (AWS Organizations and Control Tower for Govern, AWS Config and Security Hub for Identify, AWS KMS and IAM for Protect, GuardDuty and Inspector for Detect, CloudWatch and Lambda for Respond, AWS Backup and CloudFormation for Recover), choosing a key control model (native KMS, BYOK, or HYOK) that matches your sovereignty and compliance requirements, enabling CloudTrail for a complete audit trail, and documenting a CSF Profile that maps your current controls to the framework’s subcategory outcomes. AWS provides the tooling; the customer owns the configuration, key management decisions, and compliance evidence collection.

What Is NIST CSF 2.0 and What Changed from Version 1?

The NIST Cybersecurity Framework (CSF) is a voluntary, risk-based framework published by the National Institute of Standards and Technology (NIST) to help organizations manage and reduce cybersecurity risk. It provides a common language, taxonomy of outcomes, and cross-references to more than 50 other cybersecurity standards and guidelines.

NIST CSF 2.0 was officially released on February 26, 2024. It makes four significant changes from CSF 1.1:

• New Govern function added: CSF 2.0 introduces a sixth core function, Govern, which sits at the center of the framework and addresses organizational context, risk strategy, roles, policies, and supply chain risk management. This function reflects the recognition that cybersecurity governance is a precondition for the other five functions to work consistently.
• Broader scope: CSF 1.1 was framed primarily around critical infrastructure. CSF 2.0 explicitly applies to organizations of any size and sector, from large enterprises to small nonprofits and schools.
• Stronger supply chain emphasis: CSF 2.0 adds dedicated subcategories under Govern and Identify for supply chain risk management, reflecting the post-SolarWinds reality of software and vendor supply chain threats.
• Implementation resources expanded: NIST released quick-start guides, community profiles, and a searchable informative references catalog alongside CSF 2.0, making it easier to operationalize in specific environments including cloud deployments.

The framework still consists of three sections: the Core (the six functions and their categories and subcategories of outcomes), Tiers (describing the maturity of an organization’s risk management practices from Partial to Adaptive), and Profiles (capturing an organization’s current and target cybersecurity posture for a specific use case or environment).

The Six NIST CSF 2.0 Core Functions Explained

Each function represents a high-level cybersecurity outcome area. In an AWS environment, specific services map to each function, and customer responsibility varies across them.

Govern (GV) is the new function in CSF 2.0. It covers organizational context, risk strategy, roles and responsibilities, policies, oversight, and supply chain cybersecurity. In AWS, this maps to AWS Organizations (account hierarchy and service control policies), AWS Control Tower (automated landing zones and guardrails), AWS Service Catalog (curated approved service portfolios), AWS Audit Manager (automated compliance evidence collection), and your internal governance processes for cloud policy approval and vendor risk assessment. The customer owns Govern almost entirely.

Identify (ID) covers asset management, risk assessment, business environment analysis, and supply chain risk identification. AWS services supporting Identify include AWS Security Hub (aggregated security findings), AWS Config (configuration inventory and compliance drift detection), AWS Systems Manager (managed instance inventory), AWS Trusted Advisor (resource utilization and security checks), and Amazon Inspector (automated vulnerability assessment for EC2 and container images).

Protect (PR) covers access control, data security, platform security, and resilience. This is the function with the most direct mapping to encryption and key management. AWS services include AWS IAM (identity and access management), AWS KMS (encryption key management), AWS CloudHSM (dedicated FIPS 140-2 Level 3 HSMs), AWS Certificate Manager (TLS/SSL certificate provisioning), AWS Shield (DDoS protection), AWS WAF (web application firewall), AWS Macie (sensitive data discovery and classification), Amazon VPC (network segmentation), and AWS Direct Connect (private network connectivity).

Detect (DE) covers continuous monitoring, anomaly detection, and adverse event detection. AWS services include Amazon GuardDuty (intelligent threat detection using ML), Amazon Macie (sensitive data exposure detection in S3), Amazon Inspector (vulnerability scanning), AWS Security Hub (centralized security finding aggregation), and Amazon Detective (security incident investigation and root cause analysis).

Respond (RS) covers incident response planning, communication, analysis, mitigation, and improvements. AWS services include AWS CloudWatch (monitoring and alerting), AWS Lambda (automated response runbooks triggered by security events), AWS Step Functions (multi-step incident response orchestration), AWS Systems Manager (operational runbooks and automation), AWS CloudTrail (audit trail for investigation), and Amazon Detective (correlation of findings for incident scoping).

Recover (RC) covers recovery planning, improvements, and communication. AWS services include AWS Elastic Disaster Recovery (formerly CloudEndure), AWS Backup (centralized backup policy and management), Amazon S3 Glacier (long-term backup archive), AWS CloudFormation (infrastructure-as-code for environment rebuild), and AWS OpsWorks (configuration management).

AWS Services Mapped to NIST CSF 2.0 Core Functions

The table below maps AWS services to NIST CSF 2.0 core functions. AWS publishes a detailed AWS Services and Customer Responsibility matrix for CSF alignment at aws.amazon.com/compliance/nist/ for granular subcategory mapping.

#	Govern	Identify	Protect	Detect	Respond	Recover
1	Organizations	Security Hub	IAM	GuardDuty	CloudWatch	Elastic DR
2	Control Tower	Config	KMS	Macie	Lambda	AWS Backup
3	Audit Manager	Trusted Advisor	CloudHSM	Inspector	Detective	CloudFormation
4	Service Catalog	Systems Manager	Certificate Manager	Security Hub	CloudTrail	S3 Glacier
5	Config (policies)	Inspector	Shield / WAF	N/A	Step Functions	Snapshot / Archive
6	N/A	VPC Flow Logs	Macie, Direct Connect, Firewall Manager, IAM Identity Center	N/A	Systems Manager	OpsWorks

Native AWS Key Management vs. External Key Management: What the CSF Protect Function Requires

The NIST CSF Protect function’s data security subcategories require that data is protected at rest and in transit, that encryption keys are managed consistently with policy, and that key lifecycle operations are logged and auditable. How you satisfy these requirements depends on which key control model you choose. There are three practical options in AWS environments.

Option 1: Native AWS KMS (AWS-Managed Keys)

AWS creates, stores, and manages your encryption keys entirely within AWS KMS. The service uses FIPS 140-2 Level 2 validated HSMs. Key material never leaves AWS KMS unencrypted. Rotation can be set to automatic (annual for symmetric keys). Every cryptographic operation generates a CloudTrail log entry.

This model is suitable for most AWS workloads. It satisfies the NIST CSF data protection and logging requirements out of the box with minimal configuration. The trade-off: AWS technically has access to the key material as part of the managed service, which may not satisfy strict data sovereignty requirements or certain regulated sectors (defense, classified, some financial services).

Option 2: BYOK (Bring Your Own Key)

BYOK means you generate your key material externally (in an on-premises HSM or an external key management system), import it into AWS KMS as a customer-managed key with imported key material, and AWS uses that imported material for encryption operations. You retain the original key material and can delete the imported key from AWS KMS if needed, effectively revoking AWS’s ability to decrypt data protected by that key.

BYOK satisfies a stronger separation of duties requirement: the organization that generated the key retains provenance over the key material. However, during active use within AWS, the plaintext key material is accessible to AWS KMS for encryption and decryption operations. BYOK does not rotate automatically through AWS KMS; you must manage the key lifecycle externally and re-import updated key material.

Option 3: HYOK (Hold Your Own Key)

HYOK means the encryption key never enters AWS. Instead, AWS encryption operations are proxied through your external key management system. AWS services that support external key stores (such as the AWS KMS XKS, External Key Store, feature released in 2022) send key requests to your external key management proxy, which performs the cryptographic operation using your key that stays in your on-premises or private cloud HSM, and returns only the result to AWS.

HYOK provides the strongest form of key sovereignty: AWS cannot access your plaintext key under any circumstance, including legal compulsion. The trade-offs are real: every AWS encryption operation adds the latency of an external call to your key management system, your key management infrastructure must have high availability and sub-50ms response times to avoid affecting application performance, and operational complexity is significantly higher.

Key Control Decision Table

Dimension	Native AWS KMS	BYOK (Imported Key)	HYOK (External Key Store)
Key material location	AWS KMS HSM (FIPS 140-2 L2)	Generated externally, stored in AWS KMS	Always in your external HSM
AWS access to plaintext key	Yes, for cryptographic ops	Yes, during active use	No
FIPS validation level	140-2 Level 2 (KMS) or Level 3 (CloudHSM)	Depends on where you generate it	Depends on your external HSM
Automatic rotation	Yes (annual for symmetric keys)	No, you manage externally	No, managed entirely externally
CloudTrail logging	Full KMS API audit trail	Full KMS API audit trail	Partial (XKS proxy must also log)
Revoke access to data instantly	Key deletion (7-30 day waiting period)	Delete imported key material (immediate)	Disconnect XKS proxy (immediate)
Operational complexity	Low	Medium	High
Latency impact	Minimal	Minimal	Adds round-trip to external KMS
Best for	Most workloads; cost and operational efficiency priority	Regulated sectors needing key provenance outside AWS	Sovereignty mandates; classified; zero-trust key control

IAM Model for NIST CSF Protect: Least Privilege in AWS

The NIST CSF Protect function’s access control subcategories (PR.AA) require that identities are authenticated, access permissions reflect least privilege, and access is reviewed periodically. In AWS, this means designing your IAM model around three principles.

Separate KMS key policies from IAM policies: A KMS key policy is the primary access control for a KMS key. An IAM policy alone is insufficient unless the key policy also grants the principal access. This separation provides an additional layer: even an IAM administrator cannot access a KMS key unless explicitly allowed in the key policy. Structure key policies to separate key administrators (who can rotate and manage the key) from key users (who can encrypt and decrypt). No single identity should have both capabilities.

Use Service Control Policies in AWS Organizations: Service Control Policies (SCPs) applied at the Organizational Unit level can prevent any principal in those accounts from using unauthorized key management operations, creating non-compliant key configurations, or disabling CloudTrail. SCPs function as guardrails that AWS evaluates before IAM policies, making them a strong mechanism for enforcing Govern-level policy across all accounts.

Enforce multi-party access for sensitive key operations: For key deletion, key import, and cross-region replication of sensitive KMS keys, use an approval workflow that requires a second authorized identity to confirm the operation. AWS does not enforce this natively for all operations, but it can be implemented through IAM condition keys and approval workflows in AWS Step Functions or AWS Systems Manager Automation.

Key Rotation and Audit Logging for NIST CSF Compliance

NIST SP 800-57 Part 1, which the CSF informatively references for cryptographic key management, establishes that cryptoperiods (the period during which a key is authorized for use) should be limited and that keys should be rotated when the cryptoperiod expires or when compromise is suspected.

In AWS KMS, automatic rotation is available for customer-managed symmetric keys. When enabled, AWS generates new cryptographic material annually, marks the new material as the active key version, and retains all previous versions for decryption of data encrypted with earlier versions. This means you never need to re-encrypt existing data to enable rotation, and the key ARN and key ID remain constant so no application changes are required. The rotation event is logged in CloudTrail under the RotateKey event type.

For BYOK imported keys, automatic rotation is not available through AWS KMS. Your external key management system must manage the rotation schedule, and you re-import new key material manually. Encryption Consulting’s HSM as a Service and cloud data protection advisory services can help design and automate this workflow for regulated environments.

Every KMS API call generates a CloudTrail record that includes the key ID, caller identity, request parameters, and response status. For NIST CSF Detect and Respond functions, CloudTrail logs should be forwarded to Amazon CloudWatch Logs and ingested into your SIEM. Configure CloudWatch alarms for anomalous patterns: unexpected key deletion requests, unusual encryption volume spikes, failed Decrypt calls from unrecognized principals, or DisableKey events.

Cost Considerations for AWS Key Management at Scale

AWS KMS pricing has two components: a per-key-per-month charge for customer-managed keys (CMKs) and a per-API-call charge for cryptographic operations. As of 2025, AWS KMS charges $1 per CMK per month and $0.03 per 10,000 API calls. AWS-managed keys (those prefixed aws/) have no per-key charge but you still pay for API calls.

For workloads with high-volume encryption operations (S3 server-side encryption, RDS encryption, EBS volume encryption at scale), the per-call cost can accumulate. Envelope encryption, where a data encryption key (DEK) is encrypted by a KMS CMK and cached locally by your application, significantly reduces the number of KMS API calls and therefore cost. AWS services like S3, RDS, and EBS handle envelope encryption automatically.

AWS CloudHSM is priced per HSM instance per hour (approximately $1.45 per hour per HSM as of 2025), plus data transfer costs. A minimum of two HSMs in separate Availability Zones is required for high availability, making the baseline cost roughly $2,100 per month for a two-HSM cluster. CloudHSM is appropriate for workloads that require FIPS 140-2 Level 3 HSM isolation, customer management of partition credentials, or custom cryptographic operations not supported by KMS.

HYOK using the AWS KMS External Key Store (XKS) does not reduce AWS KMS API costs but adds the infrastructure cost of your external key management system and its high-availability requirements. The operational overhead is significant; factor in staffing time for managing the XKS proxy, your external HSM cluster, and the integration with AWS services.

Multi-Cloud and Hybrid Architecture Considerations

Organizations operating in AWS alongside other cloud providers (Azure, GCP) or hybrid on-premises environments face a specific NIST CSF challenge: the CSF outcomes apply to your full environment, not just your AWS footprint. This creates a key management consistency problem. AWS KMS is AWS-specific; Azure Key Vault is Azure-specific; GCP Cloud KMS is GCP-specific. Without a cross-cloud key management layer, you end up with three separate key inventories, three separate audit trails, and three separate rotation policies.

Three patterns address this:

• Cloud-native federation with unified CLM: Keep native key services per cloud (AWS KMS, Azure Key Vault, GCP Cloud KMS) but deploy a unified certificate and key lifecycle management platform that aggregates inventory, enforces rotation policy, and provides a single audit trail across all providers. This avoids the latency and complexity of HYOK while providing governance visibility across the full multi-cloud estate.
• Centralized external key management with BYOK into each cloud: Use a single external key management system as your authoritative key store and export BYOK key material to each cloud provider’s KMS. This centralizes key generation and lifecycle policy while using native cloud encryption capabilities for performance.
• HYOK with a shared external HSM: For the highest sovereignty requirements, use a single external HSM cluster as the authoritative key store and configure each cloud’s external key store integration to call your centralized HSM. This is the most operationally complex option and requires an external HSM cluster that can handle the combined encryption API call volume from all cloud providers.

Encryption Consulting’s cloud data protection advisory services and HSM as a Service offering can support each of these patterns. For organizations building a CBOM (Cryptographic Bill of Materials) as part of their NIST CSF Govern and Identify function implementation, CBOM Secure provides automated discovery and inventory of cryptographic assets across cloud and hybrid environments.

AWS Cloud Adoption Framework and NIST CSF Alignment

Before building a CSF-aligned security architecture in AWS, use the AWS Cloud Adoption Framework (CAF) to identify capability gaps. The AWS CAF’s Security Perspective covers identity and access management, detective controls, infrastructure security, data protection, and incident response, all of which map directly to NIST CSF functions.

The AWS CAF Security Perspective’s Foundational Capabilities and the AWS Security Reference Architecture (SRA) provide prescriptive guidance on how to structure AWS accounts (using AWS Organizations), which security services to deploy in which account type (a dedicated Security Tooling account for GuardDuty, Security Hub, CloudTrail aggregation), and how to enforce baseline controls across the organization. Reviewing the AWS CAF and SRA before implementing CSF controls prevents common misconfigurations and aligns your AWS architecture to AWS-recommended security patterns.

NIST CSF Shared Responsibility: Customer-Owned vs. AWS-Owned

AWS operates under a shared responsibility model that divides security accountability between AWS and the customer. For NIST CSF compliance purposes, this means your evidence collection must span both parties.

AWS-owned responsibilities include physical data center security, hypervisor and host OS patching for managed services, the availability and durability of managed services (S3, RDS, KMS), and the FIPS validation of AWS KMS and CloudHSM hardware. AWS provides audit artifacts covering these controls through AWS Artifact (SOC reports, PCI DSS attestations, ISO certifications), which customers can download and reference in their own compliance evidence packages.

Customer-owned responsibilities include IAM configuration (who can access which AWS resources and under what conditions), encryption key configuration (which KMS keys protect which data, what the key policies allow), network controls (security group rules, VPC flow log configuration, NACLs), workload hardening (OS patching on EC2 instances you manage, container image security), monitoring configuration (which CloudWatch alarms are set, which GuardDuty findings are routed to incident response), and data classification and handling procedures.

AWS publishes a detailed AWS Services and Customer Responsibility matrix for CSF alignment at aws.amazon.com/compliance/nist/. This matrix maps each of the 108 CSF outcome-based security activities to whether they are AWS-owned, customer-owned, or shared, giving security and compliance teams a starting point for gap assessment against your current control implementation.

The AWS NIST CSF architecture reference diagram illustrates the mapping of all six CSF 2.0 core functions to AWS-native services and the split between customer-owned and AWS-owned responsibilities. The full mapping is available in the AWS whitepaper “Aligning to the NIST Cybersecurity Framework in the AWS Cloud” (updated January 2025) and the downloadable AWS Services and Customer Responsibility matrix at aws.amazon.com/compliance/nist/.

How to Implement NIST CSF 2.0 in AWS: A Structured Starting Sequence

For teams beginning or refreshing their NIST CSF alignment in AWS, a structured implementation sequence reduces rework and surfaces the highest-risk gaps first.

1. Establish the Govern foundation: Set up AWS Organizations with a defined account hierarchy. Deploy AWS Control Tower to automate baseline guardrails. Define your CSF Profile for this AWS environment by documenting which CSF subcategories are in scope, what your current state is, and what your target state is. Assign ownership of each function to named individuals or teams.
2. Complete the asset and cryptographic inventory (Identify): Use AWS Config, Systems Manager, and Security Hub to inventory all AWS resources. Use CBOM Secure to discover and classify all cryptographic assets, including KMS keys, certificates, SSH keys, and secrets. This baseline inventory is the input to your risk assessment and your NIST CSF Profile current state.
3. Choose your key control model (Protect): Based on your regulatory requirements, data sensitivity, and operational capacity, decide between native AWS KMS, BYOK, or HYOK for each data classification tier. Document this decision in your key management policy, which is part of the CSF Govern function’s policy requirements.
4. Configure access controls (Protect): Design and deploy KMS key policies, IAM policies, and SCPs that implement least-privilege access. Enforce MFA for sensitive console operations and key management actions. Configure IAM Identity Center (formerly AWS SSO) for federated access with your corporate identity provider.
5. Enable monitoring and detection (Detect): Enable AWS CloudTrail in all regions with log file validation and delivery to a dedicated Security Tooling account. Enable GuardDuty across all accounts and aggregate findings in Security Hub. Configure CloudWatch alarms for key management anomalies. Enable VPC Flow Logs for network-level visibility.
6. Build response runbooks (Respond): Document and automate incident response for the findings your detection tools surface. Build Lambda-based or Step Functions-based automated responses for GuardDuty findings with high confidence. Document escalation paths, communication templates, and external notification requirements (breach notification timelines, regulatory reporting).
7. Test and validate recovery (Recover): Test AWS Backup restore procedures, document recovery time objectives (RTO) and recovery point objectives (RPO) for each critical workload, and confirm that recovery procedures restore services to the pre-incident security posture, not just operational availability.
8. Assess against the CSF Profile and iterate: Compare your implemented controls to your target CSF Profile. Document evidence for each subcategory. Use AWS Audit Manager to automate evidence collection for AWS-controllable subcategories. Identify remaining gaps and prioritize remediation by risk impact.

How Encryption Consulting Can Help

Encryption Consulting is an applied cryptography and cybersecurity firm with ISO/IEC 27001:2022 and SOC 2 certifications. We help organizations design, assess, and operate encryption and key management programs that satisfy NIST CSF, NIST SP 800-53, CMMC, FedRAMP, PCI DSS, HIPAA, and other compliance requirements in AWS and multi-cloud environments.

• Cloud Data Protection and Key Management Advisory: We assess your current AWS key control model, identify gaps against NIST CSF Protect requirements, and design the right key management architecture for your regulatory environment and risk tolerance. Whether you need native KMS optimization, BYOK key import automation, or HYOK design with AWS KMS XKS, we build the architecture and evidence documentation. See our advisory services.
• HSM as a Service: For workloads requiring FIPS 140-2 Level 3 HSM key storage outside AWS KMS, Encryption Consulting’s HSM as a Service provides dedicated HSM infrastructure with managed operations, key ceremony facilitation, and integration with AWS CloudHSM and third-party key management systems.
• CBOM Secure for Cryptographic Inventory: NIST CSF 2.0’s Govern and Identify functions require knowing what cryptographic assets you have and where they are. CBOM Secure automates discovery and classification of encryption keys, certificates, SSH keys, secrets, and cryptographic algorithm usage across your AWS environment and generates a Cryptographic Bill of Materials (CBOM) in CycloneDX format for compliance reporting.
• Compliance Advisory (NIST CSF, CMMC, FedRAMP): We facilitate NIST CSF Profile workshops, map your current AWS controls to CSF subcategories, identify gaps, and build the remediation roadmap and evidence package for your audit. Our Compliance Advisory Services cover NIST CSF 2.0, NIST SP 800-53 Rev. 5, CMMC Level 2 and Level 3, and FedRAMP requirements.
• PQC Readiness in AWS: NIST finalized post-quantum cryptography standards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024, and NIST IR 8547 points toward deprecating RSA and ECC around 2030. Our PQC Readiness service assesses your AWS cryptographic posture against the post-quantum migration timeline and designs the algorithm transition plan for your KMS key configurations, certificate profiles, and TLS configurations.

To discuss your NIST CSF alignment requirements in AWS, contact Encryption Consulting.

Conclusion

NIST CSF 2.0 represents a significant maturation of the framework. The addition of the Govern function puts organizational accountability and supply chain risk at the center of cybersecurity practice rather than treating them as secondary concerns. For AWS environments, this means the compliance work starts before you configure a single security service: you need to define your account hierarchy, assign ownership, and document your risk strategy before mapping services to the remaining five functions.

The key control decision, specifically whether to use native AWS KMS, BYOK, or HYOK, is the most consequential technical choice for the Protect function. It affects your ability to revoke access instantly, your operational complexity, your audit evidence, and your cost. Make this decision deliberately based on your actual regulatory requirements and operational capacity, not on the assumption that more control is always better.

AWS provides a comprehensive set of services that map to every CSF 2.0 function. The customer’s job is to configure them correctly, connect them to a coherent monitoring and response workflow, and maintain the evidence trail that demonstrates the controls are operating effectively over time. That evidence trail, combined with the CSF Profile you document and maintain, is what turns a good AWS security architecture into a defensible, audit-ready compliance posture.

Frequently Asked Questions

What is NIST CSF 2.0 and how is it different from CSF 1.0?

NIST CSF 2.0 was released on February 26, 2024. It adds a sixth core function called Govern to the original five (Identify, Protect, Detect, Respond, Recover), expands the scope from critical infrastructure to all organizations, strengthens supply chain risk management, and introduces supplemental implementation guides and quick-start resources. The Govern function addresses organizational context, risk strategy, roles, policies, and supply chain oversight.

What is the difference between BYOK and HYOK in AWS?

BYOK (Bring Your Own Key) means you generate key material externally and import it into AWS KMS. AWS uses that key for encryption operations, so AWS has access to the key during use. HYOK (Hold Your Own Key) means the key never enters AWS; encryption operations are proxied through your external HSM via the AWS KMS External Key Store (XKS). AWS never touches the plaintext key in HYOK, providing the strongest key sovereignty at the cost of significant operational complexity and added latency.

Which AWS services support the NIST CSF 2.0 Govern function?

AWS Organizations (account hierarchy and service control policies), AWS Control Tower (automated guardrails and landing zones), AWS Service Catalog (approved service portfolios), AWS Config (policy-as-code compliance rules), and AWS Audit Manager (automated compliance evidence collection) are the primary services supporting the Govern function. The customer retains full ownership of Govern outcomes; AWS provides the tooling to operationalize governance at scale.

How does AWS KMS support NIST CSF key management requirements?

AWS KMS provides FIPS 140-2 Level 2 validated HSM-backed key storage, automatic annual rotation for customer-managed symmetric keys, fine-grained key policies and IAM-based access control, and CloudTrail integration logging every cryptographic operation. For FIPS 140-2 Level 3 requirements, AWS CloudHSM provides dedicated single-tenant HSM hardware. Both services satisfy the NIST CSF Protect function’s data security and key management subcategories.

What is the shared responsibility model for NIST CSF compliance in AWS?

AWS secures the physical infrastructure, hypervisor, and managed service availability (security of the cloud). Customers are responsible for IAM configuration, encryption key management, network controls, workload hardening, monitoring configuration, data classification, and incident response (security in the cloud). AWS provides audit artifacts through AWS Artifact; customers must collect evidence for their portion of controls independently. The AWS Services and Customer Responsibility matrix for CSF at aws.amazon.com/compliance/nist/ maps responsibility for all 108 CSF outcome-based activities.

How should I rotate encryption keys in AWS to meet NIST CSF requirements?

Enable automatic rotation for AWS KMS customer-managed symmetric keys. This rotates key material annually while preserving the key ARN and all existing permissions, satisfying NIST SP 800-57 rotation guidance without requiring data re-encryption. For BYOK imported keys, manage rotation externally and re-import updated key material. Monitor rotation events in CloudTrail under the RotateKey event type and alert on rotation failures.

References

1. NIST Cybersecurity Framework 2.0. National Institute of Standards and Technology. Released February 26, 2024. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
2. Aligning to the NIST Cybersecurity Framework in the AWS Cloud (updated for CSF 2.0). Amazon Web Services. January 2025. https://d1.awsstatic.com/whitepapers/compliance/NIST_Cybersecurity_Framework_CSF.pdf
3. AWS Services and Customer Responsibility Matrix for Alignment to the CSF. Amazon Web Services. https://aws.amazon.com/compliance/nist/
4. NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations. NIST. https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
5. NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management. NIST. https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final
6. NIST IR 8547, Transition to Post-Quantum Cryptography Standards. NIST. https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
7. ISO/IEC 27001:2022, Information Security Management Systems. ISO. https://www.iso.org/standard/27001