SC.L2-3.13.3 (NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2) requires that Controlled Unclassified Information (CUI) in transit be protected using approved cryptographic mechanisms; IAM policies and resource policies are practical, enforceable tools you can use to ensure that cloud resources only accept encrypted, TLS-based, or otherwise cryptographically-protected connections—this post shows how to implement that in AWS and Azure with action-ready examples and small-business scenarios.
Understanding SC.L2-3.13.3 and the role of IAM/resource policies
At its core, SC.L2-3.13.3 is about ensuring confidentiality and integrity while CUI moves between systems or clients and cloud services. IAM, resource, and governance policies don't provide the cryptography themselves, but they enforce how services are used—blocking non-TLS access, requiring server-side encryption headers, forcing use of Key Management Service (KMS)/Key Vault keys, and restricting use of unapproved protocols. For a small business pursuing the Compliance Framework, that enforcement is often the difference between "we encrypt" and "we can prove we prevented insecure transmission."
AWS: Practical IAM and resource policy implementations
In AWS, use a combination of S3 bucket policies, IAM policies, KMS key policies, VPC endpoint conditions and Service Control Policies (S CPs) to enforce in-transit encryption. The most common controls are: deny requests that do not use TLS (aws:SecureTransport), deny PutObject when SSE headers are missing, require SSE-KMS with a specific CMK, and restrict access to only approved VPC endpoints or source IP ranges. Apply these at the resource (bucket, KMS key) and account management levels for layered enforcement.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyInsecureTransport",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::example-bucket",
"arn:aws:s3:::example-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "DenyUnEncryptedObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::example-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
}
]
}Additional practical details: to force SSE-KMS with a specific KMS key, add a bucket policy condition like "s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:...:key/your-key-id". Use KMS key policies to restrict which IAM roles can call kms:GenerateDataKey and kms:Decrypt for that key—this creates strict cryptographic control boundaries. Also use AWS Organizations SCPs to prevent creation of public buckets or use of older TLS versions at account level.
VPC endpoints and endpoint-only access
To prevent data exfiltration over the internet, require S3 access through a specific VPC endpoint by setting a bucket policy condition like "aws:SourceVpce": "vpce-xxxxx". Combine that with aws:SecureTransport to ensure requests over the VPC endpoint are still TLS-protected. For logs and audit evidence, enable CloudTrail (management and data events) and S3 access logging so you can show auditors that non-TLS and non-KMS access attempts were denied.
Azure: Using Azure Policy and RBAC to enforce encryption-in-transit
Azure uses Azure Policy and resource properties to enforce TLS and secure transfers; Azure RBAC controls who can change those settings. For example, storage accounts expose supportsHttpsTrafficOnly and minimumTlsVersion properties. Use Azure Policy definitions assigned at subscription or management group level to deny creation or update of storage accounts that allow HTTP or use TLS 1.0/1.1. For Key Vault, ensure only authorized principals have get/unwrapKey permissions and use firewall rules or private endpoints to limit network access.
{
"properties": {
"displayName": "Deny storage accounts without secure transfer or minimum TLS 1.2",
"policyRule": {
"if": {
"allOf": [
{ "field": "type", "equals": "Microsoft.Storage/storageAccounts" },
{
"anyOf": [
{ "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly", "equals": "false" },
{ "field": "Microsoft.Storage/storageAccounts/minimumTlsVersion", "notEquals": "TLS1_2" }
]
}
]
},
"then": { "effect": "deny" }
}
}
}Practical Azure notes: set Key Vault network rules to allow only selected virtual networks or service endpoints, enable "Require private endpoint" where possible, and assign Key Vault access via Azure RBAC (or Vault access policies) limiting wrapKey/unWrapKey and sign/verify to service principals used by your applications. Use Azure Policy to enforce Key Vault soft-delete and purge protection for compliance evidence.
Small-business scenario and step-by-step implementation
Imagine a 20-person subcontractor storing CUI in an S3 bucket and replicating backups to Azure Blob: start by inventorying all buckets/blobs that may contain CUI. Apply the AWS S3 bucket policy templates above to each S3 bucket, enable default encryption with SSE-KMS, create a CMK whose key policy only allows a defined set of roles to use it, and attach an SCP to prevent disabling secure transport or default encryption. In Azure, assign the "deny storage accounts without secure transfer" policy at the subscription level, enable minimum TLS 1.2, and put Key Vault behind a private endpoint. Test by attempting uploads with curl (HTTP) and verify the requests are denied; capture CloudTrail and Azure Activity Logs as evidence for auditors.
Compliance tips, operational best practices and automation
Best practices: 1) Treat these policies as code—store them in Git and deploy via Terraform/ARM/Bicep for repeatability. 2) Use least-privilege KMS/Key Vault key policies and rotate keys on a schedule aligned with your compliance plan. 3) Implement monitoring and alerting (CloudWatch Events/Logs, Azure Monitor) for denied insecure attempts. 4) Include policy tests in CI (attempt the non-compliant action and expect denial) so changes don't regress enforcement. 5) Keep an asset-to-CUI mapping as auditors will expect you to demonstrate which resources map to CUI and how policies protect it.
Risk of not implementing SC.L2-3.13.3 enforcement
Failing to enforce in-transit cryptographic protections leaves CUI exposed to interception, man-in-the-middle attacks, and accidental exfiltration. For a small contractor this can mean losing contracts, failing audits, regulatory fines, damaged reputation, and potential downstream compromise of prime contractors. Beyond compliance penalties, the technical risk is immediate: plaintext or weakly-protected transmission is a common path for data breaches.
Summary: To satisfy SC.L2-3.13.3 under the Compliance Framework, combine resource-level policies (S3 bucket/KMS key policies, Azure storage and Key Vault settings) with account-level governance (SCPs, Azure Policy), RBAC restrictions, and continuous monitoring—use the example JSON snippets above as starting points, treat policies as code, test in non-production, and maintain audit logs so you can demonstrate to auditors that only cryptographically-protected in-transit paths are permitted.
