Quick question for the security history buffs: which hyperscaler first made server-side encryption at rest the default for object storage, and in what year? I’m mapping timelines to NIST SP 800–53 SC-13/SC-28 and CIS Benchmark control coverage to assess residual risk in legacy buckets.
Google Cloud Storage, 2013 — default at-rest SSE; aligns with SC-28. Double-check pre-2013 buckets; Default encryption at rest | Security | Google Cloud Documentation.
I remember Google flipping this in 2013 — “encryption at rest by default” for Cloud Storage; source: https://cloudplatform.googleblog.com/2013/08/encryption-at-rest-by-default.html. In audits, my quick win is an org-wide sweep for buckets missing a defaultKmsKeyName and backfilling CMEK where SC‑13 needs customer-managed keys; do you need CMEK or is provider-managed sufficient for your legacy scope?
Agree with @elaine_q63: “2013”… Also, audit S3 created pre‑2023; AWS made default then.
GCS led in 2013 for object buckets with on‑disk crypto enabled by default; the gotcha is CMEK for Storage didn’t land until 2017, which is what typically closes SC‑12/SC‑13 gaps beyond provider‑managed keys… From experience, split your timeline accordingly and auto‑flag legacy buckets missing a KMS key via gcloud storage buckets list --format=‘value(name,defaultKmsKeyName)’ and verify against https://cloud.google.com/storage/docs/customer-managed-encryption.
Looks like GCS was first in 2013; AWS didn’t flip the switch until Jan 2023 (https://aws.amazon.com/about-aws/whats-new/2023/01/amazon-s3-default-encryption/). For your SC‑13/SC‑28 mapping, treat that as SC‑28 covered but mark SC‑13 “partial” unless CMEK/KMS is enforced; on legacy S3, require s3:x-amz-server-side-encryption in a bucket policy. , the naming across vendors muddies SC‑13 — @elaine_q63, do you have Azure’s exact cutover date for Blob?