Does your website use third-party services? Get GDPR compliant in minutes.
Try FlowConsentFree plan · 10-min setup
Microsoft Azure Maps is a cloud mapping and location service providing interactive maps, search, routing and geolocation via the Azure Maps web control or REST APIs. Visitor IP addresses and map queries reach Microsoft servers. Although Microsoft offers an EU Data Boundary, transfers to the US remain possible, requiring GDPR disclosure and appropriate safeguards.
Microsoft Azure Maps is a suite of mapping and location services built into the Microsoft Azure cloud platform. It provides interactive map rendering via the Azure Maps Web SDK (a JavaScript map control), as well as REST APIs for search, routing, traffic, weather and geolocation. Web applications integrate it by loading the Azure Maps SDK from Microsoft CDN and making API calls to atlas.microsoft.com, authenticated with a subscription key or a Microsoft Entra (formerly Azure Active Directory) token. The service is aimed at enterprise developers who need mapping functionality tightly integrated with other Azure services.
Every request to the Azure Maps API sends the visitor's IP address and the specific map query (tile coordinates, search terms, routing waypoints) to Microsoft servers. The Azure Maps Web SDK may cache authentication tokens (azureMapsToken) in browser session storage or local storage, which is subject to Article 5(3) of the ePrivacy Directive. Search queries can include place names or addresses that, in context, may reveal personal information about the user. Azure Maps sets minimal traditional cookies; it relies primarily on tokens and local caching mechanisms.
Using Azure Maps on a public website creates GDPR obligations for the transfer of visitor IP addresses and map queries to Microsoft. If the SDK writes to browser storage (session storage or local storage), Article 5(3) of the ePrivacy Directive is triggered and prior consent is required. Even without storage, the IP address constitutes personal data under GDPR. Microsoft offers an EU Data Boundary for Azure services, which keeps most processing within the EU and EEA, but some data such as support and security telemetry may still flow to the United States, making the processing a potential international transfer under Chapter V GDPR.
Get GDPR compliant in 10 minutes
Free plan available · No credit card required
If the Azure Maps SDK writes to browser storage (for token caching), consent is required under Article 5(3) ePrivacy before the SDK loads. If EU Data Boundary is configured and storage can be avoided (e.g. using server side proxied tokens), legitimate interest under GDPR may be a viable basis for the residual IP transfer, provided a balancing test is documented. For most public websites, the pragmatic and legally robust approach is to gate the Azure Maps SDK behind a cookie consent banner and load it only after the user grants map consent.
Microsoft operates a global infrastructure and even with the EU Data Boundary enabled, certain service components may transfer data to Microsoft entities in the United States. Microsoft relies on the EU US Data Privacy Framework adequacy decision and standard contractual clauses for such transfers. You must disclose the potential US transfer in your privacy policy, identify Microsoft as a data processor or controller as applicable, and ensure the Microsoft Azure Data Processing Addendum (DPAA) or equivalent agreement is in place for your Azure subscription.
To implement Azure Maps in a GDPR compliant manner: (1) Gate the Azure Maps Web SDK behind your CMP and only load it after consent, or confirm EU Data Boundary covers your scenario and document legitimate interest. (2) Avoid exposing the Azure Maps subscription key in client side code; use server side token proxying with Entra authentication. (3) Disclose Azure Maps token caching in browser storage in your cookie and storage policy. (4) Reference Microsoft EU Data Boundary and US transfer safeguards (EU US DPF, SCCs) in your privacy policy. (5) Ensure the Microsoft DPAA is signed for your Azure subscription. (6) Enable Azure diagnostic logging to keep an audit trail of API queries involving personal data.
Websites using Microsoft Azure Maps must obtain user consent under GDPR regulations.
DPIA considerations
A DPIA should be considered when Azure Maps is used on high traffic public sites or in contexts where map queries reveal sensitive information such as health, religious or political locations. Key risk areas include: (1) transmission of visitor IP addresses and map query parameters to Microsoft with every API call; (2) potential processing in the United States despite the EU Data Boundary option; (3) any storage of tokens or map state in the browser triggering ePrivacy Article 5(3); (4) use of the Azure Maps subscription key in client side code, which if exposed could allow misuse. Organisations should evaluate the scope of location data processed, document whether EU Data Boundary is configured for their Azure account, and assess whether a cross border transfer risk still exists.
Sample consent text
We use Microsoft Azure Maps to display interactive maps on this page. Loading the map sends your IP address and map queries to Microsoft. Do you agree to load the interactive map? [Load Map] [No thanks]
Third-party domains contacted
atlas.microsoft.com*.atlas.microsoft.comCookies placed
| Name | Type | Duration | Purpose |
|---|---|---|---|
| azureMapsToken | Functional (session storage) | Session | Authentication token cache used by the Azure Maps Web SDK to store and reuse Microsoft Entra access tokens for Azure Maps API calls |
| AzureMapsTelemetry | Analytics (local storage) | Persistent (local storage) | Stores an anonymous identifier used for Azure Maps usage telemetry. This collection can be disabled in the map control configuration to approach a cookieless setup. |
| msal.token.cache | Functional (session storage) | Session | When Microsoft Entra authentication is used, the MSAL library caches access tokens in session storage so the Azure Maps control can authenticate tile and search requests. |
This service may collect user data. Ensure GDPR compliance with FlowConsent.
Azure Maps sets minimal traditional cookies. The primary storage mechanism is browser session storage or local storage used by the Azure Maps Web SDK to cache authentication tokens (azureMapsToken). This token caching reduces the number of token refresh calls but constitutes access to terminal equipment storage, triggering Article 5(3) of the ePrivacy Directive. If you use server side token proxying and disable client side caching, the storage footprint is significantly reduced, potentially enabling a legitimate interest argument for the map.
It depends on your implementation. If the Azure Maps Web SDK writes authentication tokens to browser storage, consent is required under Article 5(3) ePrivacy before the SDK loads. If you proxy token requests server side and avoid any browser storage writes, and if Microsoft EU Data Boundary is configured for your Azure account, legitimate interest may be arguable for the residual IP transfer. In practice, most public website implementations should use consent as the legal basis and gate the map behind a CMP.
Two potential legal bases exist: (1) Consent under Article 6(1)(a) GDPR and Article 5(3) ePrivacy Directive where the SDK stores tokens in browser storage. This is the safest and most recommended basis for public websites. (2) Legitimate interest under Article 6(1)(f) GDPR where browser storage is avoided through server side token proxying, EU Data Boundary is configured, and the residual IP transfer is disclosed. In either case you must document the legal basis in your Records of Processing Activities and reference it in your privacy policy.
Potentially yes, even with the Microsoft EU Data Boundary enabled. The EU Data Boundary keeps most Azure Maps data processing within the EU and EEA, but Microsoft's global operations mean that support data, telemetry and security operations may still involve US based Microsoft entities. Microsoft relies on the EU US Data Privacy Framework and standard contractual clauses for such residual transfers. You must disclose this in your privacy policy and reference the Microsoft Online Services DPA which covers Azure Maps.
A DPIA may be required in certain contexts. Factors pointing toward a DPIA include: using Azure Maps search or routing APIs that process location queries at scale, integrating Azure Maps into applications that handle health, financial or other sensitive categories of data, operating on high traffic public pages where systematic IP collection occurs, and any residual transfer to Microsoft in the US despite the EU Data Boundary. Consult your DPO and check whether Azure Maps features on your supervisory authority's DPIA mandatory list.
Steps for compliant implementation: (1) Gate the Azure Maps Web SDK behind your CMP; load it only after consent is given, or implement server side token proxying and document legitimate interest if EU Data Boundary is configured. (2) Use Microsoft Entra (AAD) token authentication instead of exposing a subscription key client side, and proxy tokens server side to avoid client side storage writes. (3) Disclose azureMapsToken storage in your cookie and storage policy if client side caching is used. (4) Reference Microsoft EU Data Boundary, EU US DPF and SCCs in your privacy policy. (5) Sign the Microsoft Online Services DPA. (6) Audit all Azure Maps API calls to confirm no sensitive location data is transmitted unnecessarily.
If you want to avoid Microsoft data processing or international transfers, consider: (1) Leaflet.js or OpenLayers with self hosted OpenStreetMap tiles, eliminating third party data flows entirely. (2) MapLibre GL JS with an EU hosted tile provider or self hosted tiles, avoiding US transfers. (3) HERE Maps, which offers EU data residency options and more granular data processing controls. (4) Maptiler Cloud configured to EU region, providing vector map tiles without US transfers. The right alternative depends on your feature requirements, budget and infrastructure capacity.
If the Azure Maps Web SDK uses client side token caching, add an entry to your cookie and storage policy for: azureMapsToken (session storage or local storage, Microsoft Corporation, purpose: authentication token cache for Azure Maps API calls, duration: session or until token expiry). If you have eliminated client side storage through server side proxying, note this in your policy and explain the residual IP transfer to Microsoft. Always link your cookie policy from your consent banner and update it when you change map providers or SDK versions.