Security Baseline for M365 Apps for enterprise v2512
Security baseline for Microsoft 365 Apps for enterprise (v2512, December 2025) Microsoft is pleased to announce the latest Security Baseline for Microsoft 365 Apps for enterprise, version 2512, is now available as part of the Microsoft Security Compliance Toolkit. This release builds on previous baselines and introduces updated, security‑hardened recommendations aligned with modern threat landscapes and the latest Office administrative templates. As with prior releases, this baseline is intended to help enterprise administrators quickly deploy Microsoft recommended security configurations, reduce configuration drift, and ensure consistent protection across user environments. Download the updated baseline today from the Microsoft Security Compliance Toolkit, test the recommended configurations, and implement as appropriate. This release introduces and updates several security focused policies designed to strengthen protections in Microsoft Excel, PowerPoint, and core Microsoft 365 Apps components. These changes reflect evolving attacker techniques, partner feedback, and Microsoft’s secure by design engineering standards. The recommended settings in this security baseline correspond with the administrative templates released in version 5516. Below are the updated settings included in this baseline: Excel: File Block Includes External Link Files Policy Path: User Configuration\Administrative Templates\Microsoft Excel 2016\Excel Options\Security\Trust Center\File Block Settings\File Block includes external link files The baseline will ensure that external links to workbooks blocked by File Block will no longer refresh. Attempts to create or update links to blocked files return an error. This prevents data ingestion from untrusted or potentially malicious sources. Block Insecure Protocols Across Microsoft 365 Apps Policy Path: User Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\Block Insecure Protocols The baseline will block all non‑HTTPS protocols when opening documents, eliminating downgrade paths and unsafe connections. This aligns with Microsoft’s broader effort to enforce TLS‑secure communication across productivity and cloud services. Block OLE Graph Functionality Policy Path: User Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\Block OLE Graph This setting will prevent MSGraph.Application and MSGraph.Chart (classic OLE Graph components) from executing. Microsoft 365 Apps will instead render a static image, mitigating a historically risky automation interface. Block OrgChart Add‑in Policy Path: User Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\Block OrgChart The legacy OrgChart add‑in is disabled, preventing execution and replacing output with an image. This reduces exposure to outdated automation frameworks while maintaining visual fidelity. Restrict FPRPC Fallback in Microsoft 365 Apps Policy Path: User Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\Restrict Apps from FPRPC Fallback The baseline disables the ability for Microsoft 365 Apps to fall back to FrontPage Server Extensions RPC which is an aging protocol not designed for modern security requirements. Avoiding fallback ensures consistent use of modern, authenticated file‑access methods. PowerPoint: OLE Active Content Controls Updated Policy Path: User Configuration\Administrative Templates\Microsoft PowerPoint 2016\PowerPoint Options\Security\OLE Active Content This baseline enforces disabling interactive OLE actions, no OLE content will be activate. The recommended baseline selection ensures secure‑by‑default OLE activation, reducing risk from embedded legacy objects. Deployment options for the baseline IT Admins can apply baseline settings in different ways. Depending on the method(s) chosen, different registry keys will be written, and they will be observed in order of precedence: Office cloud policies will override ADMX/Group Policies which will override end user settings in the Trust Center. Cloud policies may be deployed with the Office cloud policy service for policies in HKCU. Cloud policies apply to a user on any device accessing files in Office apps with their AAD account. In Office cloud policy service, you can create a filter for the Area column to display the current Security Baselines, and within each policy's context pane the recommended baseline setting is set by default. Learn more about Office cloud policy service. ADMX policies may be deployed with Microsoft Intune for both HKCU and HKLM policies. These settings are written to the same place as Group Policy, but managed from the cloud. There are two methods to create and deploy policy configurations: Administrative templates or the settings catalog. Group Policy may be deployed with on premise AD DS to deploy Group Policy Objects (GPO) to users and computers. The downloadable baseline package includes importable GPOs, a script to apply the GPOs to local policy, a script to import the GPOs into Active Directory Group Policy, updated custom administrative template (SecGuide.ADMX/L) file, all the recommended settings in spreadsheet form and a Policy Analyzer rules file. GPOs included in the baseline Most organizations can implement the baseline’s recommended settings without any problems. However, there are a few settings that will cause operational issues for some organizations. We've broken out related groups of such settings into their own GPOs to make it easier for organizations to add or remove these restrictions as a set. The local-policy script (Baseline-LocalInstall.ps1) offers command-line options to control whether these GPOs are installed. "MSFT Microsoft 365 Apps v2512" GPO set includes “Computer” and “User” GPOs that represent the “core” settings that should be trouble free, and each of these potentially challenging GPOs: “DDE Block - User” is a User Configuration GPO that blocks using DDE to search for existing DDE server processes or to start new ones. “Legacy File Block - User” is a User Configuration GPO that prevents Office applications from opening or saving legacy file formats. "Legacy JScript Block - Computer" disables the legacy JScript execution for websites in the Internet Zone and Restricted Sites Zone. “Require Macro Signing - User” is a User Configuration GPO that disables unsigned macros in each of the Office applications. If you have questions or issues, please let us know via the Security Baseline Community or this post. Related: Learn about Microsoft Baseline Security Mode
Modernizing Applications by Migrating Code to Use Managed Identity with Copilot App Modernization
Migrating application code to use Managed Identity removes hard‑coded secrets, reduces operational risk, and aligns with modern cloud security practices. Applications authenticate directly with Azure services without storing credentials. GitHub Copilot app modernization streamlines this transition by identifying credential usage patterns, updating code, and aligning dependencies for Managed Identity flows. Supported Migration Steps GitHub Copilot app modernization helps accelerate: Replacing credential‑based authentication with Managed Identity authentication. Updating SDK usage to token‑based flows. Refactoring helper classes that build credential objects. Surfacing libraries or APIs that require alternative authentication approaches. Preparing build configuration changes needed for managed identity integration. Migration Analysis Open the project in Visual Studio Code or IntelliJ IDEA. GitHub Copilot app modernization analyzes: Locations where secrets, usernames, passwords, or connection strings are referenced. Service clients using credential constructors or static credential factories. Environment‑variable‑based authentication workarounds. Dependencies and SDK versions required for Managed Identity authentication. The analysis outlines upgrade blockers and the required changes for cloud‑native authentication. Migration Plan Generation GitHub Copilot app modernization produces a migration plan containing: Replacement of hard‑coded credentials with Managed Identity authentication patterns. Version updates for Azure libraries aligning with Managed Identity support. Adjustments to application configuration to remove unnecessary secrets. Developers can review and adjust before applying. Automated Transformations GitHub Copilot app modernization applies changes: Rewrites code that initializes clients using username/password or connection strings. Introduces Managed Identity‑friendly constructors and token credential patterns. Updates imports, method signatures, and helper utilities. Cleans up configuration files referencing outdated credential flows. Build & Fix Iteration The tool rebuilds the project, identifies issues, and applies targeted fixes: Compilation errors from removed credential classes. Incorrect parameter types or constructors. Dependencies requiring updates for Managed Identity compatibility. Security & Behavior Checks GitHub Copilot app modernization validates: CVEs introduced through dependency updates. Behavior changes caused by new authentication flows. Optional fixes for dependency vulnerabilities. Expected Output A migrated codebase using Managed Identity: Updated authentication logic. Removed credential references. Updated SDKs and dependencies. A summary file listing code edits, dependency changes, and items requiring manual review. Developer Responsibilities Developers should: Validate identity access on Azure resources. Reconfigure role assignments for system‑assigned or user‑assigned managed identities. Test functional behavior across environments. Review integration points dependent on identity scopes and permissions. Learn full upgrade workflows in the Microsoft Learn guide for upgrading Java projects with GitHub Copilot app modernization. Learn more Predefined tasks for GitHub Copilot app modernization Apply a predefined task Install GitHub Copilot app modernization for VS Code and IntelliJ IDEAMigrating Application Credentials to Azure Key Vault with GitHub Copilot App Modernization
Storing secrets directly in applications or configuration files increases operational risk. Migrating to Azure Key Vault centralizes secret management, supports rotation, and removes embedded credentials from application code. GitHub Copilot app modernization accelerates this process by identifying credential usage areas and generating changes for Key Vault integration. What This Migration Covers GitHub Copilot app modernization helps with: Detecting secrets hard‑coded in source files, config files, or environment variables. Recommending retrieval patterns using Azure Key Vault SDKs. Updating application code to load secrets from Key Vault. Preparing configuration updates to remove stored credentials. Surfacing dependency, version, and API adjustments required for Key Vault usage. Project Analysis Once the project is opened in Visual Studio Code or IntelliJ IDEA, GitHub Copilot app modernization analyzes: Hard‑coded credentials: passwords, tokens, client secrets, API keys. Legacy configuration patterns using .properties, .yaml, or environment variables. Azure SDK usage and required upgrades for Key Vault integration. Areas requiring secure retrieval or replacement with a managed identity. Migration Plan Generation The tool creates a step‑by‑step migration plan including: Introducing Key Vault client libraries. Mapping existing credential variables to Key Vault secrets. Updating configuration loading logic to retrieve secrets at runtime. Integrating Managed Identity authentication if applicable. Removing unused credential fields from code and configuration. Automated Transformations GitHub Copilot app modernization applies targeted changes: Rewrites code retrieving credentials from files or constants. Generates Key Vault retrieval patterns using SecretClient. Updates build dependencies to current Azure SDK versions. Removes unused configuration entries and environment variables. Build & Fix Iteration The project is rebuilt and validated: Fixes constructor changes related to updated clients. Resolves missing dependency versions. Corrects updated method signatures for Key Vault API calls. Rebuilds until no actionable errors remain. Security & Behavior Checks The tool surfaces: CVEs introduced by new or updated libraries. Behavior changes tied to lazy loading of secrets at runtime. Optional fixes or alternative patterns if Key Vault integration affects existing workflows. Expected Output After modernization: Credentials removed from source and config files. Application retrieves secrets from Azure Key Vault. Updated Azure SDK versions aligned with Key Vault. A summary file detailing code changes, dependency updates, and review items. Developer Responsibilities Developers should: Provision Key Vault resources and assign required access policies. Validate permissions through Managed Identity or service principals. Test application startup, error handling, and rotation scenarios. Review semantic impacts on components relying on early secret loading. Refer to the Microsoft Learn guide on upgrading Java projects with GitHub Copilot app modernization for foundational workflow details. Learn more Predefined tasks for GitHub Copilot app modernization Apply a predefined task Install GitHub Copilot app modernization for VS Code and IntelliJ IDEAModernizing Spring Framework Applications with GitHub Copilot App Modernization
Upgrading Spring Framework applications from version 5 to the latest 6.x line (including 6.2+) enables improved performance, enhanced security, alignment with modern Java releases, and full Jakarta namespace compatibility. The transition often introduces breaking API changes, updated module requirements, and dependency shifts. GitHub Copilot app modernization streamlines this upgrade by analyzing your project, generating targeted changes, and guiding you through the migration. Supported Upgrade Path GitHub Copilot app modernization supports: Upgrading Spring Framework to 6.x, including 6.2+ Migrating from javax to jakarta Aligning transitive dependencies and version constraints Updating build plugins and configurations Identifying deprecated or removed APIs Validating dependency updates and surfacing CVE issues These capabilities align with the Microsoft Learn quickstart for upgrading Java projects with GitHub Copilot app modernization. Project Setup Open your Spring Framework project in Visual Studio Code or IntelliJ IDEA with GitHub Copilot app modernization enabled. The tool works with Maven or Gradle projects and evaluates your existing Spring Framework, Java version, imports, and build configurations. Project Analysis When you trigger the upgrade, GitHub Copilot app modernization: Detects the current Spring Framework version Flags javax imports requiring Jakarta migration Identifies incompatible modules, libraries, and plugins Validates JDK compatibility requirements for Spring Framework 6.x Reviews transitive dependencies impacted by the update This analysis provides the foundation for the upgrade plan generated next. Upgrade Plan Generation GitHub Copilot app modernization produces a structured plan including: Updated Spring Framework version (6.x / 6.2+) Replacements for deprecated or removed APIs jakarta namespace updates Updated build plugins and version constraints JDK configuration adjustments You can review the plan, modify version targets, and confirm actions before the tool applies them. Automated Transformations After approval, GitHub Copilot app modernization applies automated changes such as: Updating Spring Framework module coordinates Rewriting imports from javax.* to jakarta.* Updating libraries required for Spring Framework 6.x Adjusting plugin versions and build logic Recommending fixes for API changes These transformations rely on OpenRewrite‑based rules to modernize your codebase efficiently. Build Fix Iteration Once changes are applied, the tool compiles your project and automatically responds to failures: Captures compilation errors Suggests targeted fixes Rebuilds iteratively This loop continues until the project compiles with Spring Framework 6.x in place. Security & Behavior Checks GitHub Copilot app modernization performs validation steps after the upgrade: Checks for CVEs in updated dependencies Identifies potential behavior changes introduced during the transition Offers optional fixes to address issues This adds confidence before final verification. Expected Output After a Spring Framework 5 → 6.x upgrade, you can expect: Updated module coordinates for Spring Framework 6.x / 6.2 jakarta‑aligned imports across the codebase Updated dependency versions aligned with the new Spring ecosystem Updated plugins and build tool configurations Modernized test stack (JUnit 5) A summary file detailing versions updated, code edits applied, dependencies changed, and items requiring manual review Developer Responsibilities GitHub Copilot app modernization accelerates framework upgrade mechanics, but developers remain responsible for: Running full test suites Reviewing custom components, filters, and validation logic Revisiting security configurations and reactive vs. servlet designs Checking integration points and application semantics post‑migration The tool handles the mechanical modernization work so you can focus on correctness, runtime behavior, and quality assurance. Learn More For prerequisites, setup steps, and the complete Java upgrade workflow, refer to the Microsoft Learn guide: Upgrade a Java Project with Github Copilot App Modernization Install GitHub Copilot app modernization for VS Code and IntelliJ IDEAUpgrade your Java JDK (8, 11, 17, 21, or 25) with GitHub Copilot App Modernization
Developers modernizing Java applications often need to upgrade the Java Development Kit (JDK), update frameworks, align dependencies, or migrate older stacks such as Java EE. GitHub Copilot app modernization dramatically speeds up this process by analyzing your project, identifying upgrade blockers, and generating targeted changes. This post highlights supported upgrade paths and what you can expect when using GitHub Copilot app modernization—optimized for search discoverability rather than deep tutorial content. For complete, authoritative guidance, refer to the official Microsoft Learn quickstart. Supported Upgrade Scenarios GitHub Copilot app modernization supports upgrading: Java Development Kit (JDK) to versions 8, 11, 17, 21, or 25 Spring Boot up to 3.5 Spring Framework up to 6.2+ Java EE → Jakarta EE (up to Jakarta EE 10) JUnit Third‑party dependencies to specified versions Ant → Maven build migrations For the full capabilities list, see the Microsoft Learn quickstart. Prerequisites (VS Code or IntelliJ) To use GitHub Copilot app modernization, you’ll need: GitHub account + GitHub Copilot Free Tier, Pro, Pro+, Business, or Enterprise Visual Studio Code Version 1.101+ GitHub Copilot extension GitHub Copilot app modernization extension Restart after installation IntelliJ IDEA Version 2023.3+ GitHub Copilot plugin 1.5.59+ Restart after installation Recommended: Auto‑approve MCP Tool Annotations under Tools > GitHub Project Requirements Java project using Maven or Gradle Git‑managed Maven access to public Maven Central (if Maven) Gradle wrapper version 5+ Kotlin DSL supported VS Code setting: “Tools enabled” set to true if controlled by your org Selecting a Java Project to Upgrade Open any Java project in: Visual Studio Code IntelliJ IDEA Optional sample projects: Maven: uportal‑messaging Gradle: docraptor‑java Once open, launch GitHub Copilot app modernization using Agent Mode. Running an Upgrade (Example: Java 8 → Java 21) Open GitHub Copilot Chat → Switch to Agent Mode → Run a prompt such as: Upgrade this project to Java 21 You’ll receive: Upgrade Plan JDK version updates Build file changes (Maven/Gradle) Dependency version adjustments Framework upgrade paths, if relevant Automated Transformations GitHub Copilot app modernization applies changes using OpenRewrite‑based transformations. Dynamic Build / Fix Loop The agent iterates: Build Detect failure Fix Retry Until the project builds successfully. Security & Behavior Checks Detects CVEs in upgraded dependencies Flags potential behavior changes Offers optional fixes Final Upgrade Summary Generated as a markdown file containing: Updated JDK level Dependencies changed Code edits made Any remaining CVEs or warnings What You Can Expect in a JDK Upgrade Typical outcomes from upgrading Java 8 → Java 21: Updated build configuration (maven.compiler.release → 21) Removal or replacement of deprecated JDK APIs Updated library versions for Java 21 compatibility Surface warnings for manual review Successfully building project with modern JDK settings GitHub Copilot app modernization accelerates these updates while still leaving space for developer review of runtime or architectural changes. Learn More For the complete, authoritative upgrade workflow—covering setup, capabilities, and the full end‑to‑end process—visit: ➡ Quickstart: Upgrade a Java project with GitHub Copilot app modernization (Microsoft Learn) Install GitHub Copilot app modernization for VS Code and IntelliJ IDEASecurity Review for Microsoft Edge version 144
We have reviewed the new settings in Microsoft Edge version 144 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 139 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 144 introduced 2 new Computer and User settings; we have included a spreadsheet listing the new settings to make it easier for you to find. As a friendly reminder, all available settings for Microsoft Edge are documented here, and all available settings for Microsoft Edge Update are documented here. Please continue to give us feedback through the Security Baselines Discussion site or this post.
Introducing Administration Client Support for the Azure Service Bus Emulator
We’re excited to announce administration client support for the Azure Service Bus emulator, extending the emulator beyond messaging operations to include management capabilities such as creating, updating, and deleting entities locally. Azure Service Bus is a fully managed enterprise message broker that supports reliable messaging through queues and publish‑subscribe topics. Since the introduction of the local emulator, developers have been able to develop and test message flows locally. With this update, the emulator now supports a broader set of workflows that depend on management operations as part of application startup or deployment. Why Administration Client support? Until now, the Service Bus emulator supported declarative entity configuration through a configuration file, allowing developers to define entities before starting the emulator. While this worked well for static setups, it limited workflows that require dynamic, runtime entity creation or management. Administration Client support unlocks on‑the‑fly entity creation and management, enabling developers to create, update, or delete entities while the emulator is running. This removes the need to restart the emulator for common management operations and brings the local development experience closer to real‑world Azure Service Bus usage. How it works By default, the emulator uses port 5300 for management operations. When performing management tasks with the Service Bus Administration Client, be sure to add the port number to the emulator connection string. Declarative configuration using the emulator’s configuration file remains supported and continues to serve as the source of truth during emulator initialization. Any configuration defined in the file is reapplied when the emulator is initialized and overrides entities created through the Administration Client, making it easy to reset or standardize local environments. For the Service Bus emulator, management operations using the Service Bus Administration Client are natively supported in .NET. Language‑specific reference samples are available to help you get started. Getting started The Azure Service Bus emulator is available as a Docker image and runs on Windows, macOS, and Linux. You can interact with the emulator using the latest Service Bus client SDKs for messaging operations, and use the Service Bus Administration Client to manage entities locally during development and testing. To explore administration scenarios, including creating and deleting queues or topics, refer to the Service Bus emulator reference samples. For more details about the emulator and supported features, visit aka.ms/servicebusemulator Share your feedback We appreciate your feedback as we continue to improve the Service Bus emulator. Please share issues, suggestions, or feature requests through the GitHub repository to help us refine the local development experience. Happy building—and may all your local tests pass! 😊
Introducing the Azure Maps Geocode Autocomplete API
We’re thrilled to unveil the public preview of Azure Maps Geocode Autocomplete API, a powerful REST service designed to modernize and elevate autocomplete capabilities across Microsoft’s mapping platforms. If you’ve ever started typing an address into a search bar and immediately seen a list of relevant suggestions—whether it’s for a landmark, or your own home—you’ve already experienced the convenience of autocomplete. What’s less obvious is just how complex it is to deliver those suggestions quickly, accurately, and in a format that modern applications can use. That’s exactly the challenge this new API is designed to solve. Why Autocomplete Matters More Than Ever The Azure Maps Geocode Autocomplete API is the natural successor to the Bing Maps Autosuggest REST API, designed to meet the growing demand for intelligent, real-time location suggestions across a wide range of applications. It’s an ideal solution for developers who need reliable and scalable autocomplete functionality—whether for small business websites or large-scale enterprise systems. Key use cases include: Store locators: When a customer starts typing “New Yo…” into store locator, autocomplete instantly suggests “New York, N.Y.” With just a click, the map centers on the right location—making it fast and effortless to find the nearest branch. Rideshare or dispatching platforms: A rideshare driver needs to pick up a passenger at “One Microsoft Way.” Instead of typing out the full address, the driver starts entering “One Micro…” and the app instantly offers the correct road segment in Redmond, Washington. Delivery services: A delivery app can limit suggestions to postal codes within a specific region, ensuring the addresses customers choose are deliverable and reducing the risk of failed shipments Any Web UIs requiring location input: From real estate search to form autofill, autocomplete enhances the user experience wherever accurate location entry is needed. What the API Can Do The Geocode Autocomplete API is designed to deliver fast, relevant, and structured suggestions as users type. Key capabilities include: Entity Suggestions: Supports both Place (e.g., administrative districts, populated places, landmarks, postal codes) and Address (e.g., roads, point addresses) entities. Ranking: Results can be ranked based on entity popularity, user location (coordinates), and bounding box (bbox). Structured Output: Returns suggestions with structured address formats, making integration seamless. Multilingual Support: Set up query language preferences via the Accept-Language parameter. Flexible Filtering: You can filter suggestions by specifying a country or region using countryRegion, or by targeting a specific entity subtype using resultType. This allows you to extract entities with precise categorization—for example, you can filter results to return only postal codes to match the needs of a location-based selection input in your web application. How It Works The Geocode Autocomplete API is accessed via the following endpoint: https://atlas.microsoft.com/geocode:autocomplete?api-version=2025-06-01-preview This endpoint provides autocomplete-style suggestions for addresses and places. With just a few parameters, like your Azure Maps subscription key, a query string, and optionally user coordinates or a bounding box, you can start returning structured suggestions instantly. Developers can further issue geocode service with the selected/ideal entity as query to locate the entity on map, which is a common scenario for producing interactive mapping experiences. Let’s look at below examples: Example 1: Place Entity Autocomplete GET https://atlas.microsoft.com/geocode:autocomplete?api-version=2025-06-01-preview &subscription-key={YourAzureMapsKey} &coordinates={coordinates} &query=new yo &top=3 A user starts typing “new yo.” The API quickly returns results like “New York City” and “New York State,” each complete with structured metadata you can plug directly into your app. { "type": "FeatureCollection", "features": [ { "type": "Feature", "properties": { "typeGroup": "Place", "type": "PopulatedPlace", "geometry": null, "address": { "locality": "New York", "adminDistricts": [ { "name": "New York", "shortName": "N.Y." } ], "countryRegions": { "ISO": "US", "name": "United States" }, "formattedAddress": "New York, N.Y." } } }, { "type": "Feature", "properties": { "typeGroup": "Place", "type": "AdminDivision1", "geometry": null, "address": { "locality": "", "adminDistricts": [ { "name": "New York", "shortName": "N.Y." } ], "countryRegions": { "ISO": "US", "name": "United States" }, "formattedAddress": "New York" } } }, { "type": "Feature", "properties": { "typeGroup": "Place", "type": "AdminDivision2", "geometry": null, "address": { "locality": "", "adminDistricts": [ { "name": "New York", "shortName": "N.Y." }, { "name": "New York County" } ], "countryRegions": { "ISO": "US", "name": "United States" }, "formattedAddress": "New York County" } } } ] } Example 2: Address Entity Autocomplete GET https://atlas.microsoft.com/geocode:autocomplete?api-version=2025-06-01-preview &subscription-key={YourAzureMapsKey} &bbox={bbox} &query=One Micro &top=3 &countryRegion=US A query for “One Micro” scoped to the U.S. yields “NE One Microsoft Way, Redmond, WA 98052, United States.” That’s a complete, structured address ready to be mapped, dispatched, or stored. { "type": "FeatureCollection", "features": [ { "type": "Feature", "properties": { "typeGroup": "Address", "type": "RoadBlock", "geometry": null, "address": { "locality": "Redmond", "adminDistricts": [ { "name": "Washington", "shortName": "WA" }, { "name": "King County" } ], "countryRegions": { "ISO": "US", "name": "United States" }, "postalCode": "98052", "streetName": "NE One Microsoft Way", "addressLine": "", "formattedAddress": "NE One Microsoft Way, Redmond, WA 98052, United States" } } } ] } Example 3: Integration with Web Application Below sample shows user enter query and autocomplete service provide a series of suggestions based on user query and location. Pricing and Billing The Geocode Autocomplete API uses the same metering model as the Azure Maps Search service. For billing purposes, every 10 Geocode Autocomplete API requests are counted as one billable transaction. This approach keeps usage and costs consistent with what developers are already familiar with in Azure Maps. Ready to Build Smarter Location Experiences? Whether you're powering a store locator, enhancing address entry, or building a dynamic dispatch system, the new Geocode Autocomplete API gives you the precision, flexibility, and performance needed to deliver seamless location intelligence. With real-world use cases already proving its value, now is the perfect time to integrate this service into your applications and unlock richer, more interactive mapping experiences. Let’s build what’s next—faster, smarter, and more intuitive. Resources to Get Started Geocode Autocomplete REST API Documentation Geocode Autocomplete Samples Migrate from Bing Maps to Azure Maps How to use Azure Maps APIs
