Icon Map for Fabric - Security Whitepaper

Published by Tekantis Ltd. Last updated 12 July 2026.

1. Introduction

This whitepaper describes the architecture and security posture of Icon Map for Fabric and Icon Map Desktop. It is written for IT security teams, Fabric administrators and network administrators evaluating or onboarding the product. It covers where data flows, which network endpoints are involved and who initiates each connection, the configuration an administrator performs, and what operational data Tekantis collects.

In scope:

• The Icon Map for Fabric workload and its item types: Icon Map, Icon Map Organizational Catalog, Tileset Builder, and Floor Plan Importer.
• The embedded viewer for maps published outside Fabric.
• Icon Map Desktop, the Windows desktop authoring application.
• The QGIS plugin (Publish to Icon Map), which publishes QGIS layers into Icon Map.

Out of scope: the Icon Map Pro and Icon Map Slicer custom visuals for Power BI, which have a separate architecture and their own security whitepaper.

Icon Map is developed and supported by Tekantis Ltd, a Microsoft Partner registered in the United Kingdom. For anything this document does not answer, contact support@icon-map.com.

2. What is a Microsoft Fabric workload?

Microsoft Fabric allows partners to extend the platform with workloads: additional item types that appear alongside native Fabric items and are built with Microsoft's Workload Development Kit. Key properties of the model:

• The workload's user interface is served by the publisher and runs inside a sandboxed iframe within the Fabric portal. It cannot access the Fabric page around it; all interaction with Fabric goes through Microsoft's workload client API. The Icon Map frontend additionally restricts which sites may frame it to Microsoft Fabric, Power BI and Teams hosts.
• Item lifecycle operations (create, save, delete) are relayed by Microsoft's Fabric service calling the publisher's backend over a server-to-server channel authenticated with Microsoft Entra tokens.
• The workload acts on user data as the signed-in user, using delegated Microsoft Entra permissions that an administrator consents to once. It inherits Fabric's existing permission model: workspace roles, item permissions and OneLake security govern what any user can see.

Microsoft's documentation for partner workloads carries a generic caution that when users interact with a workload, "their data and access tokens, including name and email, are sent to the publisher", and that sensitivity labels are not applied to workload items. Section 4 explains precisely what Tekantis receives and what happens to it; the summary is that tokens are used transiently to act on the user's behalf and Icon Map stores map content in your OneLake, not on Tekantis servers.

3. Architecture

Icon Map for Fabric consists of three Tekantis-operated services and the customer's own Fabric tenant.

Frontend - app.iconmap.ai (Azure Static Web App) The map editor and viewer UI, loaded as an iframe by the Fabric portal. It is static content only and holds no data.

Backend - api.iconmap.ai (Azure App Service) Two separate surfaces. The control plane receives item lifecycle calls (create, save, delete) made server-to-server by Microsoft's Fabric service. The data plane serves the browser: short-lived OneLake SAS minting, the CORS fetch proxy, the download relay, and telemetry ingestion. Every data-plane call requires a valid Microsoft Entra token.

Embedded viewer - embed.iconmap.ai (Azure App Service) Serves embedded maps: maps an author has explicitly published for use outside Fabric, in the organization's own websites and applications. This is distinct from simply viewing a map inside Fabric, which never involves this service. The viewer reads the published files from the customer's OneLake at view time. Embedded publishing can be disabled for your organization entirely (section 4).

Your Fabric tenant (Microsoft) Where the actual content lives: map definitions, data sources, published output, write-back edits and source credentials are all stored inside the Icon Map item in your OneLake, protected by your workspace roles.

Identity and authentication

• Users sign in with their Microsoft Entra identity. All data access in the editor and Fabric viewer is delegated: Icon Map acts as the signed-in user and can only reach data the user is already permitted to see, including row-level security on Power BI semantic models.
• Every data-plane call to the Icon Map backend requires a valid Microsoft Entra JWT, verified against Microsoft's published signing keys. There is no anonymous data-plane access and no API-key fallback.
• Browser reads of OneLake files use a short-lived, user-delegated SAS obtained on the user's behalf, so the browser talks directly to OneLake.
• Published (embedded) maps are the one case involving a non-user identity: a Tekantis reader service principal that an administrator explicitly grants access to each publishing workspace. See Set up publishing.

The permission model, credential storage and write-back gating are described in more depth in Security & permissions.

4. Your data stays in your tenant

The default data path involves no Tekantis infrastructure:

• The browser reads OneLake files directly using user-delegated SAS, and queries Fabric sources (Lakehouse, Warehouse, semantic models, Eventhouse) under the user's own identity.
• Querying, filtering and rendering happen client-side, in the browser (including SQL over Parquet via an in-browser DuckDB engine). Your data is not routed through Tekantis servers to draw a map.
• Everything Icon Map writes (map definitions, published output, write-back edits, uploaded files, source credentials) is stored in the Icon Map item in your OneLake, protected by your workspace roles.

The exceptions are deliberate, narrow, and listed here so they are never a surprise in a proxy log:

CORS fetch proxy. Layers that load resources from a customer-supplied external URL (WMS/WMTS servers, XYZ or PMTiles endpoints, GTFS feeds, image overlays, and OGC vector services - WFS and OGC API - Features) are fetched directly by the browser first. If the external host does not send CORS headers, the request automatically falls back to a server-side fetch through api.iconmap.ai, which retrieves the resource and returns it unchanged. Properties of the proxy:

• It only ever fetches the external, author-configured resource; OneLake and Fabric data never pass through it. Requests to internal and link-local addresses, the Azure instance-metadata endpoint, Azure Key Vault, Azure Storage and Fabric's own hosts are blocked outright (server-side request forgery protection).
• Requests carrying a stored credential (for example an authenticated WMS service) always use the proxy so the secret stays server-side and never reaches the browser.
• Responses are relayed, not retained. Usage is metered by byte count and destination hostname only.
• External data providers can be disabled for your whole tenant on request, which turns the proxy off.

OGC vector services (WFS and OGC API - Features). A shapes layer can connect to a live WFS 2.0 or OGC API - Features endpoint that the author configures. These are ordinary customer-configured external hosts (section 5.4): the browser fetches the service's capabilities and its features directly, or through the CORS fetch proxy above when the host lacks CORS headers - exactly the WMS policy. Only the author-supplied service URL is contacted; no OneLake or Fabric data is sent to it, and no service data is stored server-side (the proxy relays, it does not retain). In this first release, authentication beyond the proxy is not supported, so no service credentials are stored.

Download relay. The Fabric iframe sandbox blocks direct file downloads, so exports (for example from the Floor Plan Importer) round-trip through the backend to trigger a browser download. The content is relayed and not retained.

Embedded maps. Publishing is an explicit author action that makes a map viewable outside Fabric (embedded in your own sites and apps); viewing maps inside Fabric never uses this path. When someone opens an embedded map, embed.iconmap.ai reads the frozen, published files from your OneLake and serves them to the viewer. Published content is read at view time and is not copied to Tekantis storage; unpublishing or revoking a link takes effect immediately. If your organization does not want maps embedded outside Fabric at all, the capability can be disabled for your tenant, or for individual workspaces: the Publish action disappears from the editor, and the embed service refuses to serve the affected published maps, including ones published before the setting was changed.

Geocoding and routing never send your locations anywhere

Icon Map's address and place search is fully client-side. The search index (built from open data) is downloaded to the browser as static, read-only index files from the Icon Map CDN and searched locally. Search terms, addresses and coordinates never leave the browser. There is no geocoding API call to Tekantis or to any third party. This is an intentional design decision: address searches are often sensitive (customers, patients, incidents), and a conventional geocoding service would expose them to an external party.

The same applies to travel-time areas (isochrones) and routing along the road network: the routing engine runs in the browser against read-only road-network tiles downloaded from the Icon Map CDN. The origins, destinations and travel-time parameters of your analysis - often your most sensitive locations - are never sent to Tekantis or to any routing API.

The SQL Workspace runs entirely in the browser

The SQL Workspace (spatial SQL over map layers, in the data tables pane) executes every query in the browser via DuckDB-WASM: no query text, result set or source data leaves the session, and the feature adds no new network endpoints. The DuckDB engine and its spatial extension are vendored and served from the workload's own origin - they are not fetched from a third-party CDN at runtime. Reads from OneLake are unchanged, using the existing short-lived user-delegated SAS under the signed-in user's permissions. Likewise, the GeoParquet and FlatGeobuf shape formats are parsed client-side in the browser, over the same author-configured URL and OneLake channels as the existing shape formats (section 5.4 applies to external URLs as usual).

The same applies to the analysis tools built on this stack:

• The Processing toolbox (buffer, dissolve, clip, spatial join and the other geoprocessing tools) computes entirely in the browser on the same in-browser DuckDB spatial engine. No layer data is sent to a processing service; there are no new endpoints.
• IDW interpolation (the interpolated-surface mode of the grid layer) is a pure client-side computation over the points already on the map, with no network access.
• Contour lines are generated in the browser from the DEM the map is already configured to use for terrain or hillshade. Contour generation reads only the already-configured DEM tile sources (section 5.4 for a custom or ArcGIS elevation URL; otherwise the CDN in section 5.1) and adds no new endpoints.

For completeness of the feature inventory: camera tours, label placement, attribute-table tools (selection and column statistics) and sun position are purely client-side rendering and UI features that introduce no new endpoints, dependencies with network access, or data flows.

Dynamic URLs configured by authors

Report authors can build layer URLs from data values (for example, switching a tile endpoint based on a field). As with any templated URL, authors should take care not to place sensitive data values into URLs sent to external services. This mirrors the guidance in the Icon Map Pro whitepaper.

5. Network endpoints and firewall allowlist

The single most common support issue in locked-down environments is a firewall or TLS-inspecting proxy silently blocking one of the endpoints below. The tables are grouped by who initiates the connection. All connections are HTTPS on port 443.

5.1 Tekantis endpoints called by the user's browser

5.2 Microsoft endpoints called by the browser or Desktop

Any tenant already running Microsoft Fabric will have these allowed; they are listed for completeness and are covered by Microsoft's own allowlist documentation.

5.3 Third-party endpoints, opt-in features only

Contacted only when an author enables the specific feature. No Fabric data is sent to them.

Spectral indices (NDVI, NDWI and the other band-math indices on a Planetary Computer layer) are computed by the Planetary Computer tiler. They add index query parameters (the band-math expression, value-range rescale and colour map) to the existing Planetary Computer tile requests listed above - no new hosts are contacted, and no imagery pixels are downloaded to the browser to compute the index.

5.4 Customer-configured endpoints

These have no fixed hostname; the author supplies the URL, and your firewall must permit whatever hosts your authors configure: WMS/WMTS servers, OGC vector services (WFS and OGC API - Features), XYZ / PMTiles / vector tile endpoints, 3D tiles, image overlays, custom terrain (an ArcGIS elevation ImageServer URL, for example), GTFS transit feeds, custom OAuth token endpoints for authenticated feeds, and ArcGIS Enterprise portals.

5.5 Connections initiated by Microsoft, not from your network

Fabric's control plane calls the Icon Map backend (api.iconmap.ai) server-to-server for item lifecycle operations, and fetches the workload manifest. These connections originate from Microsoft's cloud, not from your network, and require no firewall configuration on your side.

5.6 Known proxy and firewall pitfalls

• HTTP Range requests are essential. Basemaps, terrain, catalog layers and the geocoding index are single-file archives (PMTiles and similar) read with Range headers, returning 206 Partial Content. A proxy that strips Range headers or rewrites 206 responses to 200 breaks maps in ways that look like data corruption. Allow range requests to the hostnames in section 5.1.
• Do not filter by content type on the allowed hosts: the CDN serves .json styles, .pbf fonts, .pmtiles archives and Parquet files, and some security appliances block these extensions by default.
• TLS inspection that re-signs certificates can break the sign-in broker inside the Fabric iframe; exempt login.microsoftonline.com and the section 5.1 hosts if users see sign-in loops.
• Cookie, popup and Conditional Access considerations are covered in Browser & network.

6. Onboarding: required configuration

The step-by-step runbook lives in Onboarding & Setup. This section summarizes every switch involved, where it lives, and the narrowest scope it can be applied at, so a security team can review the footprint before enabling anything.

6.1 Making the workload available

Microsoft Fabric gives administrators three scopes for enabling a partner workload, managed from the Fabric Admin portal (Manage Workloads) and governed by the tenant settings under Additional workloads:

A cautious rollout can therefore start with Icon Map enabled on one capacity or one workspace and expand later. Workload assignments are also manageable programmatically through Microsoft's Workload Management admin APIs.

6.2 Entra ID consent

A one-time, tenant-wide admin consent to the Icon Map application removes per-user consent prompts. All requested permissions are delegated (act-as-the-user); the application receives no standing access to your data. The permission list and both grant methods are documented in Grant admin consent.

Icon Map uses separate Entra ID applications per product surface, so you consent only to what you actually deploy, and each application carries the minimum permissions for its job:

Every permission in the table is delegated - each application acts as the signed-in user and can never reach data that user cannot already access. Application (client) IDs for consent are provided by your onboarding contact and are visible under Entra ID, Enterprise applications once used.

6.3 Fabric tenant settings

Fabric's tenant-setting delegation model (tenant to capacity or domain, then optionally to workspace) applies to a fixed set of settings chosen by Microsoft. Of the settings above, item creation supports a per-capacity override and the SAS authentication setting is workspace-delegated by default; the others are tenant settings whose narrowing mechanism is security groups. Combined with per-capacity workload enablement (section 6.1), a pilot can be contained to one capacity, with data access restricted to a pilot security group.

Publishing additionally requires the explicit, per-workspace grant of the reader service principal described in Set up publishing; Icon Map never grants itself workspace access.

A minimum viable deployment (authoring and viewing maps inside Fabric, no publishing) needs only the workload enablement, admin consent, and the first four settings above.

7. Item types

Icon Map The map item itself. Its definition, uploaded files and source credentials live in the item's OneLake folder; data sources are read under the user's identity.

Organizational Catalog A curated internal layer library. Access to its layers is governed by OneLake permissions on the catalog's repository folder; there is no separate sharing system to audit.

Tileset Builder Generates vector tilesets from OneLake files using your own Fabric Spark capacity. Source data and generated tiles never leave your tenant.

Floor Plan Importer Converts CAD floor plans in the browser; the CAD file is not uploaded to Tekantis. Exports use the download relay (section 4).

8. Icon Map Desktop

Icon Map Desktop is a Windows application (built on Electron) providing the same map authoring experience against local files and, when signed in, Fabric data.

• Local-first. Maps are stored as .iconmap files with sidecar assets on the user's machine. Working locally requires no server component and no sign-in.
• Sign-in is standard Microsoft Entra (MSAL) against login.microsoftonline.com, using a dedicated Icon Map Desktop application (separate from the workload's - see the application table in section 6.2), to browse workspaces, read OneLake data and deploy maps to Fabric. The same delegated-permission model as the workload applies.
• Network footprint. The map asset CDN and catalog endpoints (section 5.1), and when signed in the Microsoft endpoints (section 5.2). Customer-configured sources (section 5.4) are fetched through a relay bound to the local loopback interface only; it accepts no remote connections.
• No self-update service of its own. The app contains no Tekantis update-check endpoint. When installed from the Microsoft Store, updates are delivered and verified through the Store's standard mechanism; the directly distributed installer is updated manually.

9. QGIS plugin: Publish to Icon Map

Currently in preview.

Tekantis provides a plugin for QGIS, the widely used open-source desktop GIS, that publishes QGIS vector layers into Icon Map: either as a local file bundle, or directly into an Icon Map item in your Fabric tenant (including creating a new map).

• Runs entirely on the user's machine inside QGIS. Layers are reprojected and exported locally, then uploaded directly to your own OneLake. Nothing is sent to Tekantis: the plugin communicates only with Microsoft endpoints (login.microsoftonline.com, api.fabric.microsoft.com, onelake.dfs.fabric.microsoft.com). The local-bundle mode involves no network access at all.
• Sign-in is a standard Microsoft Entra device-code flow using a dedicated multi-tenant application, Icon Map QGIS Connector. All permissions are delegated: the plugin acts as the signed-in user and can only reach workspaces and items that user already has access to.
• Admin consent is scoped to what you enable. Browsing workspaces and maps by name uses Fabric read permissions that are admin-restricted in most tenants, so a tenant administrator consents to the application once (the plugin includes a consent helper). Without admin consent, a reduced mode lets users publish by pasting workspace and item IDs, using only the user-consentable OneLake permission.
• Minimal supply-chain surface. The plugin is implemented with the Python standard library only; it has no third-party Python dependencies.

10. Telemetry, metering and privacy

Tekantis collects operational telemetry from the Fabric workload to run the service, measure usage against plans, and diagnose faults. Its design principles:

What is never collected. Map data, query results, coordinates, addresses, search terms, file contents, semantic model data, free-text of any kind. Events are validated server-side against a fixed registry of event names and typed properties, so arbitrary payloads cannot enter the pipeline; the single documented exception is the destination hostname (only) of external-source fetches, recorded for cost attribution.

What is collected. Event name (for example map viewed, layer added, map published), product version, tenant ID, workspace and item identifiers, coarse feature properties (layer kind, data source kind, catalog tier), and byte counts for metered relays.

Pseudonymous identity. Telemetry never stores names, emails or raw user identifiers. The per-user identifier is a keyed hash (HMAC-SHA256) of tenant and user IDs, computed server-side. The hash key is held only by Tekantis; destroying it renders all historical identifiers permanently anonymous (crypto-erasure), which is also the mechanism used to honour erasure requests.

Always-on vs optional. Usage metering (the counts that license plans are billed against) is always on. Diagnostics (error and fault telemetry) can be disabled for your tenant on request.

Storage and retention. Telemetry is stored in Tekantis' Azure subscription, separate from all product infrastructure serving your users. Raw events are retained for up to 25 months; aggregated, non-identifiable statistics are retained thereafter. In-flight buffers on the service are pruned within 14 days.

The workload's telemetry is sent only to the Icon Map backend (api.iconmap.ai); the workload does not embed any third-party analytics SDK, and no telemetry goes to third parties. Tekantis Ltd acts as a data controller for this operational data under UK GDPR; contractual terms are set out in the license agreement.

11. AI-assisted features

The Icon Map Catalog offers an optional AI-assisted catalog search to help authors discover datasets from a natural-language prompt. Its scope is deliberately narrow:

• Only the author's search prompt and catalog metadata (dataset titles and descriptions) are processed, by models hosted in Microsoft Azure AI Foundry. Your Fabric data, map data and report data are never sent to any AI model.
• No customer prompts or data are used by Tekantis to train AI models.
• Results are presented as suggestions for the author to review; no automated decisions are made about individuals.
• The feature can be disabled for your organization.

In development: MCP authoring server. Tekantis is building a Model Context Protocol (MCP) server that will let organizations connect their own AI assistants and agents to Icon Map so that maps can be authored programmatically. Its security properties are fixed by design even though the feature is not yet released:

• The server exposes authoring tools and a published JSON schema for map configurations; it does not include or host an AI model. The model is the customer's own choice and runs wherever the customer's agent runs - Tekantis does not process prompts and does not route your data to any AI model in this flow.
• The server acts under the signed-in user's delegated identity, so an agent can only read the data sources, and create or update the maps, that its user is already permitted to access. Maps it creates are ordinary Icon Map items in the customer's own workspace and OneLake.

This section will be updated with full details when the capability enters preview.

Tekantis governs its AI features under a formal, risk-based process aligned with the EU AI Act (Regulation (EU) 2024/1689) and the NIST AI Risk Management Framework. AI-assisted catalog search has been assessed as a minimal-risk feature. For the full position, feature assessments and governance documents, see AI Act compliance.

12. Development and supply-chain practices

• The product is written in TypeScript and built from a private, access-controlled source repository with mandatory code review.
• At each release, npm audit is run across the dependency tree, and releases do not ship with known unresolved vulnerabilities in runtime dependencies.
• The open-source foundations are widely used, actively maintained projects (MapLibre GL, deck.gl, DuckDB, Apache Arrow, React, Fluent UI). The full component and license list is maintained at Third-party components.
• Secrets are held in Azure service configuration, never in source code or client bundles. Client-side code receives no standing credentials: only short-lived, scoped tokens.
• Source code review: Tekantis can make source code available under NDA for your security team's review. Penetration testing of your own tenant's usage can be arranged; please coordinate with us first so tile-service load is planned. Contact support@icon-map.com.

13. Infrastructure

Tekantis services run in Microsoft Azure (European regions) behind Azure-managed TLS. Static map assets are cached at the edge via Azure Front Door. The frontend is static content; the backend holds no customer map data at rest. Service configuration and secrets are managed through Azure App Service configuration with access limited to Tekantis operations staff.

14. Quick answers for security reviewers

Is our data sent to or stored by Tekantis? Map content is stored in your OneLake and rendered in the browser. Exceptions are transit-only: the CORS proxy (external author-configured resources), the download relay, and embedded-map serving. See section 4.

Do address searches or travel-time analyses leave our network? No. Geocoding and road-network routing both run entirely in the browser against downloaded index and tile files; search terms, addresses, origins and destinations never leave the browser.

Can we prevent maps being embedded outside Fabric? Yes. Embedded publishing can be disabled for your tenant or per workspace: the Publish action is removed and the embed service refuses to serve the affected maps. Viewing maps inside Fabric is unaffected.

What do we need to allowlist? The Tekantis hosts in section 5.1 plus the standard Microsoft Fabric endpoints. Make sure HTTP Range requests pass through unmodified.

Can we limit who gets Icon Map? Yes: enable it per capacity or per workspace, and scope the tenant settings to security groups. See section 6.

Does Icon Map get standing access to our tenant? No. All authoring access is delegated (as the signed-in user). The only service principal is the publishing reader, granted per workspace by your administrator and removable at any time.

Can external calls be restricted? External data providers (and with them the CORS proxy) can be disabled for your tenant; third-party map services are opt-in per feature.

What telemetry is collected? Registry-validated usage events with pseudonymous identifiers; no map data, no free text. Diagnostics can be disabled. See section 10.

Can our security team review the code? Yes, under NDA. Contact support@icon-map.com.

Next steps

• Onboarding & Setup - the administrator runbook.
• Security & permissions - the permission model in detail.
• Data, privacy & residency - the data-residency principles.
• Third-party components - open-source components and licenses.