ImportError: cannot import name 'x509' from 'cryptography.hazmat.bindings._rust' when importing azure.identity

TL;DR: Your cryptography install is broken, not azure.identity. The compiled Rust extension (_rust) does not match the installed cryptography package, so anything importing cryptography.x509 (which azure.identity does at load time) blows up. Reinstall with pip install --force-reinstall --no-cache-dir cryptography and the import works.

from azure.identity import DefaultAzureCredential
...
File ".../azure/identity/_internal/aadclient_certificate.py", line 7, in [module]
    from cryptography import x509
...
ImportError: cannot import name 'x509' from 'cryptography.hazmat.bindings._rust' (unknown location)

Fix it

1. Confirm cryptography is the culprit: python -c "from cryptography import x509". Expected: the same ImportError, which proves azure.identity is innocent.
2. Note the version: pip show cryptography. Expected: a version number to compare after the reinstall.
3. Reinstall cleanly: pip install --force-reinstall --no-cache-dir cryptography. Expected: Successfully installed cryptography-x.y.z, with a wheel matching your platform and Python.
4. Verify: python -c "from azure.identity import DefaultAzureCredential; print('ok')". Expected: ok.
5. On Azure App Service: make sure the app actually runs from the virtualenv you fixed. Set the startup command or app setting to point at that venv's Python, or rebuild the deployment so oryx installs fresh.

When this applies

• Any from azure.identity import ... fails deep inside cryptography with the _rust ImportError.
• It worked locally but fails on the server: classic wheel mismatch from copying site-packages across machines.

When it doesn't

• The import works but token calls fail: that is a credential problem, not this one.
• You see DLL load failed instead: same family, but the fix may need the Visual C++ redistributable on Windows.

Compatibility

• azure-identity any recent version; cryptography 38+ (Rust-based bindings).

Why it happens

cryptography ships compiled Rust code. If pip installs a version whose _rust extension was built for a different setup (stale cache, copied venv, partial upgrade), the Python side cannot find x509 in it, and every importer of cryptography.x509 fails.

Edge cases

• --no-cache-dir matters: a poisoned wheel cache will just reinstall the same broken files.
• Pin cryptography in requirements once fixed so the next deploy does not drift again.