On May 14, 2026, the Azure SDK team announced that the Azure SDK for Rust moved from beta to stable, with 1.0 releases of the Core, Identity, Key Vault (Secrets, Keys, Certificates), and Storage (Blobs, Queues) crates. For government developers who have been waiting for a supported, idiomatic Rust path to Azure, this is the green light. Rust is no longer just a community experiment for Azure workloads, it is a first-class, Microsoft-supported language for building services that handle sensitive data.

This post walks through the new azure_storage_blob 1.0.0 crate, authentication with azure_identity 1.0.0, and a hands-on pattern for a secure file ingestion service. It also explains why the memory-safety story matters for state and local agencies that are being pushed by federal guidance toward memory-safe languages.

What actually shipped in May 2026

The relevant stable crates published the week of May 11-14, 2026 on crates.io are:

• azure_core 1.0.0
• azure_identity 1.0.0
• azure_storage_blob 1.0.0 (published 2026-05-13)
• azure_storage_queue 1.0.0 (published 2026-05-13)
• azure_security_keyvault_secrets / _keys / _certificates 1.0.0

Full release notes are on the azure-sdk-for-rust releases page. The Blob 1.0.0 release consolidated the constructor surface: every client now has a single new() that takes a fully-formed Url, and a number of helpers (such as with_tags() on the upload options) were added. If you were on a beta, expect breaking changes around from_url() and pageable APIs like find_blobs_by_tags().

A quick note on Azure Government: the SDK itself is cloud-agnostic. You select the sovereign cloud by pointing the client at the correct endpoint, for example https://<account>.blob.core.usgovcloudapi.net/ for the US Gov Virginia and Arizona regions, instead of blob.core.windows.net. Managed identity and Microsoft Entra ID authentication work the same way in both clouds.

Why Rust, why now, for government

The White House ONCD report on memory-safe programming languages (February 2024) called on software producers to move away from memory-unsafe languages for systems software. CISA followed with its Secure by Design guidance, which explicitly identifies adopting memory-safe languages as a core practice. Roughly 70% of severe security bugs Microsoft tracks across its products historically trace back to memory safety issues in C and C++ code.

Rust gives you the runtime performance profile of C++ with compile-time guarantees against the bug classes that drive a large share of CVEs: use-after-free, buffer overruns, data races, and double frees. For a county or city that is running ingestion services in front of records management, body-worn camera footage, GIS imagery, or court documents, that is not an academic point. It directly reduces the attack surface that ransomware crews and nation-state actors probe first.

Until now, the practical blocker for many shops was tooling: no stable, Microsoft-supported Azure SDK meant either rolling your own REST client or accepting the maintenance burden of a community crate. The 1.0 release closes that gap.

Setting up a project

Assuming a recent stable Rust toolchain (Rust 1.78 or newer), start a new binary crate and add the dependencies:

1
2
3
4
5

cargo new gov-ingest --bin
cd gov-ingest
cargo add azure_core azure_identity azure_storage_blob
cargo add tokio --features full
cargo add anyhow tracing tracing-subscriber

The Storage crate’s README on GitHub is the authoritative quickstart, and the executable examples in the examples/ folder (such as blob_storage_upload_file.rs for streaming large files) are worth reading before you write much of your own code.

Authentication: managed identity, no secrets in code

The pattern you want in production is ManagedIdentityCredential. In local development, fall back to DeveloperToolsCredential, which chains Azure CLI and azd logins. Both come from azure_identity 1.0.0.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

use azure_core::credentials::TokenCredential;
use azure_identity::{DeveloperToolsCredential, ManagedIdentityCredential};
use std::sync::Arc;

pub fn credential() -> anyhow::Result<Arc<dyn TokenCredential>> {
    if std::env::var("IDENTITY_ENDPOINT").is_ok()
        || std::env::var("MSI_ENDPOINT").is_ok()
    {
        Ok(ManagedIdentityCredential::new(None)?)
    } else {
        Ok(DeveloperToolsCredential::new(None)?)
    }
}

Grant the hosting compute (App Service, Container Apps, AKS pod identity, or a VM) the Storage Blob Data Contributor role on the target storage account. The role assignment guidance for blob data is the same for commercial and US Gov clouds.

No connection strings. No account keys. No secrets to rotate, leak, or commit. This is the posture that matches CISA’s secure-by-design guidance and that auditors increasingly expect on StateRAMP and FedRAMP-adjacent workloads.

A secure file ingestion service

Here is the shape of a minimal HTTP ingestion service that accepts an upload, writes it to a blob container, tags it with provenance metadata, and returns the resulting blob URL. The example uses Axum for HTTP, but the SDK calls are the point.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

use axum::{
    extract::{Multipart, State},
    http::StatusCode,
    routing::post,
    Json, Router,
};
use azure_core::http::{RequestContent, Url};
use azure_storage_blob::{
    models::BlockBlobClientUploadOptions, BlobServiceClient,
};
use std::{collections::HashMap, sync::Arc};

mod auth; // contains credential() from the previous snippet

#[derive(Clone)]
struct AppState {
    service: Arc<BlobServiceClient>,
    container: String,
}

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    tracing_subscriber::fmt::init();

    let account = std::env::var("STORAGE_ACCOUNT")?;
    let endpoint_suffix = std::env::var("STORAGE_ENDPOINT_SUFFIX")
        .unwrap_or_else(|_| "blob.core.windows.net".to_string());
    let service_url = Url::parse(
        &format!("https://{account}.{endpoint_suffix}/"))?;

    let credential = auth::credential()?;
    let service = Arc::new(BlobServiceClient::new(
        service_url,
        Some(credential),
        None,
    )?);

    let state = AppState {
        service,
        container: std::env::var("INGEST_CONTAINER")?,
    };

    let app = Router::new()
        .route("/ingest", post(ingest))
        .with_state(state);

    let listener = tokio::net::TcpListener::bind("0.0.0.0:8080").await?;
    axum::serve(listener, app).await?;
    Ok(())
}

async fn ingest(
    State(state): State<AppState>,
    mut multipart: Multipart,
) -> Result<Json<serde_json::Value>, (StatusCode, String)> {
    let field = multipart
        .next_field()
        .await
        .map_err(|e| (StatusCode::BAD_REQUEST, e.to_string()))?
        .ok_or((StatusCode::BAD_REQUEST, "missing file".into()))?;

    let filename = field
        .file_name()
        .map(|s| s.to_string())
        .unwrap_or_else(|| uuid::Uuid::new_v4().to_string());

    let bytes = field
        .bytes()
        .await
        .map_err(|e| (StatusCode::BAD_REQUEST, e.to_string()))?;

    let mut tags = HashMap::new();
    tags.insert("classification".to_string(), "cui".to_string());
    tags.insert("source".to_string(), "ingest-api".to_string());

    let options = BlockBlobClientUploadOptions::default().with_tags(tags);

    let container = state.service.blob_container_client(&state.container);
    let blob = container.blob_client(&filename);

    blob.upload(
        RequestContent::from(bytes.to_vec()),
        Some(options),
    )
    .await
    .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    Ok(Json(serde_json::json!({ "blob": filename })))
}

For commercial Azure leave STORAGE_ENDPOINT_SUFFIX unset. For Azure US Government, set it to blob.core.usgovcloudapi.net. The exact same binary runs in both clouds.

A few production details to layer on:

• For files above a few MB, switch to the streaming pattern in blob_storage_upload_file.rs. The 1.0 Block Blob client supports staged block uploads and concurrent upload of blocks, which is critical for ingestion of body camera footage or large GIS files.
• Enable immutable blob storage with time-based retention policies on the destination container for records that fall under public records laws.
• Configure the storage account with customer-managed keys in Key Vault and disable shared-key authorization at the account level so managed identity is the only path in.
• Wire the SDK into OpenTelemetry using the blob_storage_logging.rs example as a starting point so storage calls show up in your existing Application Insights or Grafana stack.

How the Rust SDK compares with .NET and Python

Functionally, the three SDKs cover the same Blob REST surface. The differences worth knowing:

• Ergonomics: The .NET SDK (Azure.Storage.Blobs) and Python SDK (azure-storage-blob) are the most mature, with the broadest sample library. Rust 1.0 covers the operations most services need (Block, Append, Page, container and service clients, tags, pageable listings) but the surface is intentionally narrower than .NET’s.
• Runtime profile: Rust binaries are static, small (single-digit MB after strip), and have no GC pauses. For container-based workloads on Azure Container Apps or AKS with tight memory limits, this matters for both density and cold-start.
• Safety: .NET and Python are memory-safe at the language level too, but Rust additionally rules out data races at compile time and forces you to handle every error path. That maps well to ingestion code that is exposed to the public internet.
• Operational fit: If your team already runs .NET on App Service, do not rewrite. Use Rust for new services where you want the smallest possible trusted compute base, or where you are replacing legacy C/C++ that has been a CVE source.

Why This Matters for Government

State and local IT shops are simultaneously being asked to (1) modernize aging C and C++ services that handle resident data, (2) demonstrate alignment with CISA Secure by Design principles, and (3) reduce the operational burden of secrets management. A supported, stable Rust SDK on Azure addresses all three:

• Memory-safe language by default, addressing the bug class that drives most exploitable CVEs in systems code.
• Managed identity end-to-end, which removes account keys and connection strings from source, configuration, and pipelines, and aligns with zero-trust guidance.
• Identical code paths between Azure commercial and Azure US Government, so a workload that starts in commercial for development can move to a GCC-aligned tenant and US Gov subscription without an SDK rewrite.
• Small static binaries that fit cleanly into the container and serverless platforms agencies are standardizing on for their next generation of resident-facing services.

The Rust SDK 1.0 is not a reason to throw away your .NET or Python investments. It is a reason to put Rust on the shortlist the next time you scope a new ingestion service, a high-throughput data mover, or a sensitive-data API where the bar for memory safety is non-negotiable.

Where to go next

• Azure SDK for Rust on GitHub - source, examples, and release notes
• azure_storage_blob on crates.io
• azure_identity on crates.io
• Assign an Azure role for access to blob data
• Azure Government storage endpoints