Azure Blob SDK client-side CRC64 integrity reaches GA

Client-side data integrity protection for Azure Blob Storage became generally available on June 29. The Azure Storage announcement says the latest .NET, JavaScript, and C++ Blob SDKs can compute and validate CRC64-NVME checksums for uploads and downloads. Azure independently verifies a write before acknowledging it, and multipart operations reconcile chunk checksums with the whole object.

Integrity reaches the application boundary

Storage services already protect data inside their systems, but bytes can change in client memory, faulty hardware, proxies, or transfer code before the service’s own checks begin. Enabling SDK validation lets an application compare what it intended to transfer with what Blob Storage accepted or returned.

A checksum detects accidental corruption; it is not authentication and does not stop a malicious party who can replace both content and checksum. Authorization, TLS, immutable retention, and application signatures solve different problems.

Roll out through the transfer layer

Confirm the language and minimum SDK version listed in the announcement, then enable StorageCrc64 in upload and download validation options. Test single-request and multipart transfers, retries, streams that cannot seek, and deliberately corrupted fixtures. Observe the exception surfaced by the SDK and ensure the application never promotes a failed object.

Measure CPU and throughput with production object sizes. CRC64-NVME is designed for efficient composition and hardware acceleration, but client platforms and concurrency differ. Define metrics for checksum failures separately from network errors.

If migrating from MD5, review consumers that depend on MD5 metadata or response limits rather than changing one enum blindly. Preserve an end-to-end content identifier where downstream systems need durable provenance. The GA capability is most useful when failure handling is explicit and tested.