Linux ARM64 (aarch64) support for MIP File SDK — roadmap inquiry

Hi @Tal Garpel , Hope you are doing well.

1. Is Linux ARM64 (aarch64) support planned? Target release or timeframe?

Not currently supported, and there is no published roadmap or ETA.

The supported platform matrix lists Linux as Ubuntu 20.04 / 22.04 / 24.04, RedHat Enterprise Linux 8 and 9, and Debian 10 and 11 — all x64, with no ARM64 variant for any distribution. macOS and Windows are the only ARM64 targets.

2. Process for a formal enhancement request, and does customer demand factor into prioritisation?

Yes, demand is a factor. The guidance given on the 2024 thread was to submit through the public feedback channel, "which would be open for the user community to upvote & comment on. This allows our product teams to effectively prioritize your request against our existing feature backlog and gives insight into the potential impact of implementing the suggested feature."

As an ISV you have a second, stronger route. If you hold an Information Protection Integration Agreement (IPIA) — the ISV onboarding agreement for MIP SDK integrators, covered in the setup and configuration article — raise it through that channel as well. A named ISV with a quantified fleet-migration impact carries materially more weight in backlog prioritisation than an anonymous forum vote. If you don't have an IPIA in place, that article explains how to request one.

When you file, include the concrete numbers: node counts, the Graviton migration timeline, and what the x64 constraint costs you. Vague "please support ARM64" requests are the easiest to deprioritise.

3. Is running the x64 Linux binaries under emulation supported?

Confirmed unsupported — you can record that in your risk register.

To be precise about what "unsupported" means here: emulation has been suggested informally as something you could attempt, with the explicit caveat that "these workarounds are not officially supported by Microsoft, and there may be compatibility issues or performance degradation." There is no supported-configuration statement covering it, so any production issue on an emulated stack would be out of scope for support.

One point specific to the File SDK that's worth adding to your risk assessment: the Linux build depends on native components — curl, libsecret, OpenSSL libssl, UUID, plus GMIME and Libgsf specifically for apps using the File SDK. A translation layer has to carry that entire native dependency chain correctly, including the OpenSSL cryptographic paths used for protection. That's a materially higher-risk surface than emulating a pure-managed workload. Your decision not to pursue it is the right call.

4. Supported alternative for file-level labeling with encryption that doesn't depend on the native SDK?

Your understanding is correct, and I'm not aware of anything that has changed. The MIP SDK is described as the mechanism by which "developers can use the SDK to build native support for applying labels and protection to files" — Graph and the Purview APIs don't expose an equivalent file-level apply-label-with-protection operation.

Given that, the realistic architectures for a mixed or ARM64 fleet are:

• Isolate labeling onto a small x64 pool. Keep the rest of the fleet on Graviton and route only label/protect operations to x64 workers over your existing service boundary. Since you already wrap the SDK in C++ with Python bindings, that wrapper is the natural place to put the network hop, and it keeps the blast radius of the constraint to one service.
• Multi-arch images with an x64-pinned node group. Build multi-arch and pin the labeling deployment to an x64 node group via node selectors, so the rest of the migration proceeds unblocked.

Either way you get most of the Graviton cost benefit without running an unsupported configuration.

Two things to check while you're planning

• You're on mip_sdk_file_ubuntu2204_1.15.107. Note that v1.18.75 removed support for Ubuntu 20.04 — 22.04 is still supported, but distro support does get retired as the SDK advances, so factor that into your base-image plan.
• Cache encryption on Linux is supported on Ubuntu 22.04 and later only, and requires SecretService plus the LinuxEncryptedCache feature flag, set via mip::MipConfiguration::SetFeatureSettings(). The docs also note "we didn't test the cache encryption on RedHat Enterprise Linux, CentOS, or Debian" — relevant if your x64 pool base image was going to change during this migration.

Kind Regards,
Microsoft Support Team.