Icon Map for Fabric - Security Whitepaper

Published by Tekantis Ltd. Last updated 12 October 2026.

1. Introduction

This whitepaper describes the architecture and security posture of Icon Map for Fabric, Icon Map Desktop and Icon Map AI. 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.

Two kinds of data are kept apart throughout. Your data is what sits in your Fabric tenant and data platform: maps, Lakehouse tables and files, and everything else in OneLake. It stays in your tenant, and Tekantis does not receive or store it (section 4). Operational data is what Tekantis holds to run its business and the service: account and contact details, license and usage records, orders, and delivery records. Section 12 lists every operational flow, which Tekantis service receives it and where it is held.

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, and the user-owns-data embedding mode for maps embedded in your own internal applications.
• Icon Map Desktop, the Windows desktop authoring application.
• Icon Map AI, the Model Context Protocol (MCP) server installed by Icon Map Desktop, through which an organization's own AI assistant can author maps.
• 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. The one exception is their organizational-catalog feature, which reaches the Icon Map for Fabric backend on the signed-in user's behalf and so is documented here in section 8.

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 four 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 and telemetry ingestion. Every data-plane call requires a valid Microsoft Entra token.

Embedded viewer - embed.iconmap.ai (Azure App Service) Serves published maps: maps an author has explicitly published for use outside Fabric, in the organization's own websites and applications, for viewers who have no Fabric access. 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).

Embed host - org.iconmap.ai (Azure Static Web App) Serves the user-owns-data embedding mode: a map embedded in the organization's own internal application where every viewer signs in with their own Microsoft Entra identity. It is static content only and holds no data. Nothing is published, nothing is copied, and no service principal exists in this path - the map is read live from the Fabric item under the viewer's own identity, so the organization's existing Fabric permissions and row-level security apply per viewer. See 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.

Tekantis business services (called by the backend, server to server) The backend also calls three Tekantis services that hold operational data only: the licensing service (license checks, trials, license assignment and usage counts), the website API (tenant policy settings, upgrade requests, and the data store) and the Icon Map Catalog API (catalog access). None of them receives map content. Section 12 describes what each one holds and where.

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.
• Embedding a map in your own internal application keeps this same delegated model end to end. Each viewer's own Entra identity is used to read the map item, its OneLake files and its live queries, so native Fabric and Power BI row-level security applies per viewer with nothing for Icon Map to reproduce or get wrong. Tokens are either supplied by your application (which already signed the user in) or obtained by the map itself through a dedicated, read-only Entra application. No Tekantis identity is involved (section 4).
• Published maps are the one case involving a non-user identity: a dedicated, read-only embed service principal used only by the public embed service. It is a separate Microsoft Entra application from the workload, authenticates with a certificate held in Azure Key Vault, and requests no API permissions. Its only access is a read-only OneLake data-access role on the specific Lakehouse that holds your published maps - granted automatically at publish, under the author's own identity. It has no write access to your workspace, and a workspace that has Icon Map installed but has never published anything is unreachable from the public embed service. Enterprises who prefer it can supply their own service principal for this read, so no vendor identity ever touches their data (see section 6.2). See Set up publishing.
• The Icon Map Power BI visuals can browse your organizational catalogs using Power BI single sign-on: the visual obtains a delegated token for the signed-in user, which the Icon Map backend exchanges on behalf of that user (OAuth 2.0 On-Behalf-Of) to list only the workspaces and catalogs the user can already access. This is the sole path by which a Power BI visual reaches the Fabric backend, and it remains fully delegated. See section 8.

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

4. Your data stays in your tenant

This section is about your data: the content in your Fabric tenant and data platform. The operational records Tekantis keeps (accounts, licenses, usage counts, orders, delivery records) are a separate matter, covered in section 12.

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.

Downloads. Files a user exports (data-table CSVs, drawn shapes, floor plans, tour videos) are saved straight from the browser to the user's device. The workload's iframe runs with Fabric's sandbox relaxation (allow-downloads), consented through the Fabric.Extend.IframeSandbox permission, so no Tekantis server is in the path and nothing is relayed or retained.

Embedded maps. A map can be embedded outside Fabric in two different modes, with different trust models. Read the mode you are actually deploying - the controls below are not interchangeable.

User-owns-data embedding. The map is embedded in your own application and every viewer signs in as themselves. There is no publish step, no copy of your data, no signed manifest and no service principal - the map item, its OneLake files and its live queries are all read under the viewer's own Entra identity, exactly as they are inside Fabric. The security properties follow directly from that:

• Icon Map cannot exceed the viewer's own permissions. There is no vendor identity in the data path at all. A viewer sees only what their Fabric permissions already allow, and a viewer whose access is removed stops seeing the data immediately, with no re-publish and nothing to revoke.
• Row-level security is Fabric's own. Per-viewer security is enforced by your Fabric and Power BI models, not reproduced by Icon Map, so there is no filter mapping to review or keep in step.
• Nothing is frozen or copied. No published snapshot of your data exists anywhere.
• org.iconmap.ai is static content only. It holds no data and has no server-side identity; it is the Fabric reading view, served outside the Fabric portal.
• Tokens. In the usual arrangement your own application supplies the access tokens, so no Tekantis Entra application is involved. If you instead let the map sign viewers in, it uses Icon Map Embed Viewer - a dedicated application holding delegated, read-only permissions and deliberately no item-write permission (section 6.2).
• Residual risk. As in Power BI's equivalent mode, a stolen access token works until it expires. Tokens are short-lived.

This mode cannot be used for public sharing: every viewer must sign in and hold Fabric permission to the data.

Published maps. Publishing is an explicit author action that makes a map viewable outside Fabric by people with no Fabric access; viewing maps inside Fabric never uses this path. When someone opens a published 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. Because this is the one anonymous, internet-facing surface in the product, it carries a set of controls designed for exactly that exposure:

• A publish cannot grant more access than its author has. At publish time, the service re-checks - under the author's own signed-in identity - that the author can access every data source, file and item the map references, and refuses the publish otherwise. The published instructions are then cryptographically signed, and the embed service verifies that signature on every read: a published map that has been altered after publishing, by anyone, is refused rather than served. Together these mean publishing can never be used to reach data its author could not already open.
• A dedicated, minimal, read-only identity. The embed service runs under its own Microsoft Entra service principal (separate from the workload and its control plane), authenticating with a certificate held in Azure Key Vault. It requests no API permissions. Its only access is a read-only OneLake data-access role on the specific Lakehouse that holds your published maps — granted automatically at publish, under the author's own identity. It has no write access to your workspace and can reach only the published output, never the rest of your data or workspaces that merely have Icon Map installed.
• Credentials never reach viewers. API keys for keyed map services (for example commercial WMTS imagery) are removed from published content at publish time, stored in your own OneLake, and attached server-side when tiles are relayed. Anonymous viewers never receive a credential of any kind.
• Viewers receive a minimal manifest. The browser-facing form of a published map contains what is needed to render it - and not the map's query text, table and file names, column lists, Fabric item identifiers or connection details, which all remain server-side.
• Embedding can be restricted to your sites. Token-gated publishes must declare an allowed list of embedding origins (wildcard subdomains supported), enforced in the browser via Content-Security-Policy; embed tokens are short-lived (four hours at most). Anonymous-link publishes are unrestricted by design - "anyone with the link" is their purpose - and both models can be disabled entirely (below).
• Abuse guardrails. Per-publish rate limits, concurrency caps and daily query budgets bound what any embedded map can consume.

Unpublishing or revoking a link takes effect within 30 seconds. 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.

Live weather is public model data, fetched anonymously

The live weather layers (rainfall, temperature, pressure, wind particles, waves, air quality) read public, open weather-model output directly in the browser - no API key, no account, and no Tekantis server in the path. The browser downloads byte ranges of global forecast files; the requests carry nothing about your map, your data or your locations. The endpoints involved, for proxy-log completeness:

• noaa-gfs-bdp-pds.s3.amazonaws.com - NOAA GFS model (US public domain)
• noaa-gefs-pds.s3.amazonaws.com - NOAA GEFS ensemble + GEFS-Aerosols (US public domain)
• ecmwf-forecasts.s3.eu-central-1.amazonaws.com - ECMWF open data, including its wave model (CC BY 4.0; attribution is added to the map automatically)

Weather is model analysis and forecast data, refreshed with each model run (roughly 6-hourly) - it is honestly labeled as such on the map, and it is not radar or live observations. If the external-data-providers setting is disabled for your tenant, weather layers are unavailable along with the other external sources.

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), sun position and the map time slider are purely client-side rendering and UI features that introduce no new endpoints, dependencies with network access, or data flows. The weather forecast-confidence overlay (ensemble spread) reads the same public NOAA GEFS bucket already listed above.

Telecoms coverage analytics run in the browser

The telecoms coverage layer (sector wedges, 3D coverage volumes, coverage occlusion, best-server dominance, estimated range, neighbor arcs, antenna patterns) is a pure client-side rendering and analysis feature. Cell data is read like any other layer source (OneLake or Fabric queries under the user's identity); all RF computation - the COST231-Hata range model, the GPU occlusion and best-server passes - happens in the browser, and nothing about your network topology is sent to Tekantis or any third party. Coverage occlusion reads only the already-configured DEM tile source and the basemap's building tiles (sections 5.1 and 5.4) and adds no new endpoints. MSI antenna pattern files are uploaded to and read from your OneLake through the existing user-delegated SAS channel. The Bulk CM notebook shipped alongside the layer is a plain, readable notebook template that runs on your own Fabric capacity under your identity: it parses vendor configuration exports from your Lakehouse files and writes a Delta table back to the same Lakehouse, with no Tekantis or third-party network access at all.

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

Icon Map Desktop and Icon Map AI call the same hosts from the user's machine rather than from the browser (sections 9 and 10). One further Tekantis hostname is involved: Icon Map Desktop posts anonymous, installation-scoped usage events to desktop-usage.iconmap.ai, an ingest endpoint isolated from the product infrastructure (section 12). Icon Map AI sends only usage records for licensing, through catalogapi.icon-map.com, with no content (section 10).

5.2 Microsoft endpoints called by the browser, Desktop or Icon Map AI

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 color 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.

The same applies to the backend's own calls to the Tekantis licensing service, website API and catalog API (section 12). They run between Tekantis services in Azure and need nothing allowed on your network.

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 - tenant, capacity or workspace - chosen when Icon Map is added from the Workload hub and governed by the tenant settings under Additional workloads. During the private preview the workload is published to a named list of tenants, so a tenant also has to be on Icon Map's preview audience before it appears in the hub.

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 two Icon Map workload applications (frontend and backend) removes per-user consent prompts. Fabric requests these consents itself - the backend application's when the workload is added, the frontend application's when the first map opens - and an administrator can grant them for the whole organization from those prompts; the admin-consent URLs are the equivalent for administrators who consent ahead of a rollout. With the single app-only exception noted on the backend row below, all requested permissions are delegated (act-as-the-user); the applications receive 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:

With the single exception noted on the backend row, 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. The Icon Map sign-in application reaches no data at all: it establishes who the user is for Tekantis' own services, and nothing more.

Why Azure Storage and Azure Data Explorer are requested on demand. Microsoft Entra consents an application's whole declared permission set at once, and refuses the lot (AADSTS650052) in any tenant that has no service principal for one of the services named - which is every tenant that has never used that service through a third-party application. Declaring only Microsoft Graph and Power BI, which every Fabric tenant has, means Icon Map can be consented in any tenant, including one created that day. The OneLake and Eventhouse permissions are then requested the first time a user connects a Lakehouse or an Eventhouse; a user in a tenant that allows user consent sees one prompt, and an administrator can pre-approve either permission for the whole organization from that prompt, from the admin-consent URL with a scope parameter, or with the Grant-IconMapResourceConsent.ps1 script. A tenant that has never used Azure Storage or Azure Data Explorer through any third-party application must first create the service's entry with one command (az ad sp create --id <service id>), as described under Before you consent; Fabric and Entra do not create it themselves, and the same step applies to every partner workload that reads OneLake.

None of these applications holds a Tenant.Read.All or Tenant.ReadWrite.All permission, the Fabric admin APIs, so none can enumerate or read anything tenant-wide. The .All suffix on the other names is Microsoft's naming convention across the whole Fabric API surface, not a statement of reach: Item.Read.All means "read the items this user is already allowed to read", and Microsoft publishes no narrower per-workspace or per-item variant to request instead.

Permission sets are kept deliberately minimal and are reviewed against the code paths that request them. Where Fabric offers a read and a read-write version of the same permission, the workload, backend and Desktop applications declare only the read-write one: it covers reads, so declaring both would lengthen the consent list without granting anything more. Application (client) IDs are listed above and are also visible under Entra ID, Enterprise applications once used.

Why the workload asks for Capacity.Read.All. It is used for one thing: when a license is assigned to a Fabric capacity, Manage licenses shows each capacity by name and size (for example "Production, F64"), so the person assigning licenses can tell capacities apart. It reads capacity metadata only, never content. If an administrator declines it, nothing else is affected: the screen falls back to showing the capacity's identifier.

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 grants the embed service principal a read-only OneLake data-access role on the publishing Lakehouse, automatically and under the author's own identity (Set up publishing). Icon Map never grants itself workspace access, and the grant is read-only, never Contributor.

Bring your own service principal (enterprise option). If you would rather no Tekantis identity read your data at all, the embed reader can be your own Microsoft Entra application instead of Tekantis.IconMap-Embed: you register the app, supply its certificate, and Icon Map's embed service authenticates as it for your tenant. You then own, audit and can revoke the identity that reads your published maps. Contact your onboarding contact to enable this. The fullest form - running the embed service entirely within your own environment so no Tekantis infrastructure is in the data path - is available as a self-hosted deployment; ask us for the self-hosted embed guide.

A minimum viable deployment (authoring and viewing maps inside Fabric, no publishing) needs only the workload enablement, admin consent to both workload applications, 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 are saved straight from the browser to the user's device (section 4, Downloads).

8. Organizational catalogs in the Power BI visuals

The Icon Map and Icon Map Slicer Power BI visuals can browse the same Organizational Catalogs (section 7) that authors curate in Fabric, so a layer library maintained once in Fabric is reusable in Power BI reports. Because a Power BI custom visual runs in a sandboxed iframe with no direct access to Fabric or OneLake, this is done through a delegated, on-behalf-of flow rather than by giving the visual any standing access.

How a user is authenticated. The catalog dialog only requests a token when the user opens the Organizational Catalogs tab - a user who never uses the feature is never prompted, and no token is requested at report load. When they do, the visual uses Power BI's built-in single sign-on (acquireAADToken) to obtain a Microsoft Entra token for the signed-in user, scoped to the Icon Map backend. Power BI issues this token itself; the visual never sees the user's credentials, and the token's audience is fixed to the Icon Map backend application by the visual's declared authentication configuration.

What the backend does with it. The visual sends only this token to api.iconmap.ai. The backend verifies it against Microsoft's published signing keys (as with every data-plane call), then performs an OAuth 2.0 On-Behalf-Of exchange to obtain short-lived Fabric and OneLake tokens for that same user. Using them, it lists the workspaces and Organizational Catalog items the user can access, reads each catalog's manifest from OneLake, and returns the catalog entries the user is entitled to see. Every hop is delegated: the service can only ever reach data the signed-in user is already permitted to see, and it holds no standing access to your tenant.

What is and isn't sent. The request to the backend carries the user's token and nothing else - no report data, no semantic-model rows, no query text. The response is catalog metadata (layer names, descriptions and styling) for catalogs the user can access. Catalog layer tiles are then read the same way as in Fabric - directly from OneLake or the catalog CDN under the user's own permissions (sections 5.1 and 5.2). Access to any catalog remains governed entirely by OneLake permissions on that catalog's folder; the visual introduces no separate sharing system.

What you enable. This feature is off until an administrator turns on the Power BI tenant setting Allow custom visuals to obtain Microsoft Entra ID access tokens (section 6.3) and the Icon Map backend application is authorized in your tenant. Everything else about the visuals - the public Icon Map Catalog, and reports that don't use organizational catalogs - is unaffected and needs none of this.

9. 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), the usage-telemetry endpoint desktop-usage.iconmap.ai (section 12), 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.
• Icon Map AI. Desktop installs the Icon Map AI MCP server under the user's profile and, at the user's request, registers it with the user's AI client. While Desktop is running, its loopback relay also serves the signed-in user's tokens to that server, so the AI client never handles a credential. Section 10 describes the server.

10. Icon Map AI: the MCP server

In private preview. Installed as part of Icon Map Desktop.

Icon Map AI lets an organization's own AI assistant author Icon Map maps: discover data, assemble a schema-valid map configuration, render a preview, and save the result as an Icon Map item in Fabric. It is delivered as a Model Context Protocol (MCP) server that Icon Map Desktop installs on the user's Windows machine. There is no Tekantis-operated component in this path: the server is a local process, and every connection it makes is listed in this section.

How it runs

• A local process, started by the AI client. The server runs on a bundled Node.js runtime under the user's profile (%AppData%\Icon Map Desktop\mcp) as a child process of the AI client, and exchanges messages with it over standard input and output. It accepts no remote connections; the only ports it opens are transient loopback (127.0.0.1) listeners used by the preview renderer and, when needed, by the sign-in redirect.
• Works with any MCP-capable AI client that supports local servers (for example Claude Desktop and Claude Code, Visual Studio Code with GitHub Copilot, and Cursor). Icon Map Desktop registers the server with the client the user chooses. The registration is a command line pointing at the local runtime and carries no credential.
• No AI model is included. The server exposes authoring tools and the published JSON schema for map configurations; the reasoning is done by whatever model the organization's AI client uses, under that client's own terms. Tekantis does not receive prompts, tool arguments or tool results from this flow, and does not route any customer data to an AI model. It receives only a usage record for each tool call (see Telemetry below).
• License check. The server makes no call at start-up. The first time a tool needs a license, it asks which Fabric workspace the user is working in, confirms with the user's own Microsoft Fabric access that they can open that workspace, and then checks the organization's entitlement for it through catalogapi.icon-map.com, using the signed-in user's Microsoft Entra identity or a license key entered in Icon Map Desktop's Settings. The request carries the product name and version, a random per-installation identifier, a per-session identifier, the workspace, and either the license key or the user's token; it contains no map content and no data. The last answer is kept, encrypted, on the user's machine, so a short outage of the Tekantis service does not interrupt licensed use: it is honoured for at most 72 hours and never beyond the license's own end date. Without a license, only the sign-in, license and help tools run.

Identity

• Delegated, as the signed-in user. The server signs in with the same Icon Map Desktop Microsoft Entra application and delegated permissions listed in section 6.2; it introduces no additional application, service principal or standing access. It can read only the data sources, and create or update only the Icon Map items, that the user is already permitted to. Workspace roles, item permissions, OneLake security and semantic-model row-level security apply unchanged, because every query runs as the user.
• Sign-in. The server signs the user in itself, with a standard Microsoft Entra authorization-code flow (PKCE) and a loopback redirect, the first time a tool needs it, never at start-up. The sign-in is cached on the user's machine, encrypted with the operating system's data protection (DPAPI on Windows) under the user's profile, so the user is not asked again each session. If Icon Map Desktop is running, the server can use Desktop's sign-in instead, through Desktop's relay on the loopback interface, authenticated with a secret generated for each Desktop launch. The AI client never handles a token or a license key.
• Entitlement check. To confirm your organization's entitlement with the user's Microsoft identity, the server asks for a token for the Icon Map sign-in application (section 6.2), which is sign-in only and reaches no data. Tekantis has pre-authorized Icon Map Desktop for it, so users are not asked to consent to it separately; a license key avoids it altogether.
• Consent for the Icon Map Desktop application covers Icon Map AI. Where the tenant allows user consent, the user can consent at first sign-in and sign-in itself succeeds. The Fabric permissions (Workspace.Read.All, Item.ReadWrite.All) are admin-restricted in most tenants, however, so browsing workspaces and reading Fabric data stay blocked until an administrator grants consent once for the organization, as the application table in section 6.2 notes. Because Azure Data Explorer is not declared on the Desktop application, the first Eventhouse or KQL query made through Icon Map AI prompts for that cluster's user_impersonation scope, or needs it pre-approved in locked-down tenants, in the same way as the workload's on-demand permissions (section 6.2).

What data goes where

The principle is the same as everywhere else in the product: data is read in place, under the user's identity, and Tekantis is not in the path. What is new is the AI client itself, which is addressed plainly below the table.

What the AI client sees. Tool results are returned to the AI client, so a bounded view of your data - the rows a query returns, the column statistics and example values a profile reports, the preview image - is visible to the assistant and to the model behind it, in the same way that a user pasting a table into that assistant would expose it. This is inherent to using an AI assistant on your data. It is governed by the terms and data handling of the AI client and model provider your organization has chosen, not by Tekantis, and organizations should apply the same policy to Icon Map AI that they apply to that assistant generally. The row caps above bound the exposure, and nothing reaches the assistant that the signed-in user could not already read.

Endpoints

Icon Map AI adds no new Tekantis hostnames and does not use the Icon Map backend (api.iconmap.ai). From the user's machine it contacts:

• styles.iconmappro.com (basemaps, fonts, terrain, the geocoding index and routing tiles), catalogapi.icon-map.com (catalog search and activation), the catalog tile hosts, mesh.iconmap.ai and iconmappropublictiles.blob.core.windows.net (preview rendering) - all from section 5.1;
• the Microsoft endpoints in section 5.2, including your Eventhouse cluster's own hostname for KQL queries;
• only when the corresponding tool is used, ArcGIS Online or your own portal (section 5.3), and the public open-data portals the user names.

The TLS-inspection and HTTP Range notes in section 5.6 apply.

Telemetry and local storage

• Usage records, no content. The server embeds no analytics SDK. For usage-based licensing it sends Tekantis one usage record per tool call, and per billable action such as a preview render, a map save, a catalog layer used or a video export, through catalogapi.icon-map.com. A record names the feature and the tool, a time, a quantity (such as video seconds) and the item or catalog entry it applies to. It never contains prompts, tool arguments, query results, map content, addresses or coordinates. Records are batched and sent within seconds; if the service cannot be reached they wait in an encrypted local queue and are sent later.
• Local files. Under the user's profile (.iconmap-mcp): the cached sign-in and the last license answer, both encrypted; the queue of usage records not yet sent; and an anonymous installation identifier. Temporary files in the operating system's temporary folder while a query, model build or video export runs, and only those output files the user asks for. A license key is held by Icon Map Desktop in encrypted settings.
• The AI client's own storage (conversation history, cached tool results) sits outside Icon Map and is governed by that client.

Controls for administrators

• Deploy and consent. Icon Map AI exists only where Icon Map Desktop is installed, and it can reach Fabric data only once the Icon Map Desktop application has been consented for the tenant, by an administrator or by the user where the tenant allows user consent (section 6.2). Every Fabric permission the user holds, and only those, apply to it; removing a user's Fabric access removes the server's access.
• Activation is per organization. The server activates against an entitlement held by your tenant or a license key issued to your organization, never anonymously.
• Endpoint control. Blocking the open-data portals or the ArcGIS hosts disables those tools only; the rest of the server is unaffected.
• Removal. Remove the server entry from the AI client's configuration, or uninstall Icon Map Desktop.

11. 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.

12. Operational data, telemetry and privacy

12.1 Two kinds of data

• Your data. Maps, item definitions, Lakehouse tables and files, Warehouse, semantic-model and Eventhouse data, published output, organizational catalogs, and data store copies once they are written to your OneLake. It stays in your tenant. Tekantis does not receive it or store it. The narrow transit-only exceptions are listed in section 4.
• Operational data. The records Tekantis keeps to run its business and the service: who our customers are, what they have licensed and where it applies, how much is used, what they have ordered, and where we delivered it. It never contains map content, query results or file contents.

12.2 Operational data, by flow

Where these services run:

Pre-filling the upgrade request form. When a user opens the upgrade request form, the backend reads that user's own profile from Microsoft Graph on their behalf (name, email address, job title, company, city, country, phone, and the organization's name), using the delegated User.Read permission. It is only used to fill in the form. Nothing is stored unless the user sends the form, and every field can be changed first.

12.3 Data store copies

When you buy a dataset from the data store, Tekantis builds the copy and the workload writes it into your OneLake as the signed-in user. From then on the copy is in your tenant, like the rest of your data. Tekantis records only where it was written (section 12.2, delivery records), never what it contains.

Tekantis never deletes anything from your Lakehouse or OneLake. When a store license ends, streaming of the dataset stops, and you are asked to stop using any copies and delete them yourself. The end-of-licence notice lists every recorded delivery so you can find them.

12.4 Third parties

GitHub holds data in the United States; HubSpot holds our CRM records in its EU data center. Transfers to the European Economic Area (HubSpot, MailerSend) rely on the UK's adequacy regulations. Transfers to the United States (GitHub, Paddle's hosting, and HubSpot support access) rely on the UK Extension to the EU-US Data Privacy Framework where the provider is certified, and otherwise on the UK International Data Transfer Addendum to the EU Standard Contractual Clauses in the provider's data processing terms. All of these transfers are encrypted in transit.

12.5 Telemetry

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 in UK South, 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. Icon Map Desktop sends its own usage events to a separate ingest endpoint, desktop-usage.iconmap.ai: a random per-installation identifier, the product version and coarse feature usage, carrying no tenant, workspace, item or user identifier and no map content. Icon Map AI sends no analytics telemetry; for usage-based licensing it sends one usage record per tool call and billable action, naming the feature and tool, with no prompts, arguments, results or map content (section 10).

Pseudonymous identity applies to telemetry only. The records in section 12.2 that need a name or email address to work (accounts, trials, upgrade requests, orders) do hold them.

Tekantis Ltd acts as a data controller for all operational data under UK GDPR; contractual terms are set out in the license agreement, and the privacy policy sets out retention periods and your rights.

13. 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.

Icon Map AI. The MCP server through which an organization's own AI assistant authors maps is described in section 10. It includes no AI model: prompts, tool calls and tool results pass only between the user's AI client and the model that client uses, and Tekantis processes none of them. Map data is read under the user's own delegated identity, and the maps it creates are ordinary Icon Map items in the customer's own workspace and OneLake.

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.

14. Development and supply-chain practices

• The product is written in TypeScript and built from a private, access-controlled source repository with mandatory code review.
• Security review before release. Changes that touch authentication, tokens, the publishing and embedding paths, or anything reachable without a signed-in user are reviewed against a written threat model for that surface, not just for correctness. Reviews are recorded, each finding is tracked to closure, and the design decisions behind them are kept as internal specifications. Where Microsoft publishes guidance for a surface - for example the authentication contract for a workload's backend endpoints - our implementation is checked against it directly.
• The internet-facing surface is re-reviewed periodically. Publishing a map for viewing outside Fabric is the only anonymous, internet-facing path in the product (section 4), so it is re-examined end to end at intervals and after significant change, rather than only when it is first built.
• 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.

15. Infrastructure

Tekantis services run in Microsoft Azure behind Azure-managed TLS, in these regions:

• UK South: the licensing service, the website and portal API, the Tekantis database (Azure SQL), and the usage and telemetry storage. All operational data in section 12.2 is held here, whatever your Fabric region.
• North Europe: the workload backend (api.iconmap.ai), the published-map service (embed.iconmap.ai), the catalog API, and the reference data (basemaps, catalog tiles, 3D mesh, fonts, routing and geocoding files).
• West Europe: AI-assisted catalog search.
• East US 2: the static workload frontend and embed host (Azure Static Web Apps, served from a global edge network; no data).
• East US: the Key Vault holding the published-map service's certificate, and the screening of opt-in support report screenshots.

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.

16. Quick answers for security reviewers

Is our data sent to or stored by Tekantis? Your data, no. Map content is stored in your OneLake and rendered in the browser. Exceptions are transit-only: the CORS proxy (external author-configured resources) and published-map serving. File exports go straight from the browser to the user's device. The user-owns-data embedding mode adds no exception - org.iconmap.ai is static content, and the data goes directly between the viewer's browser and Microsoft. See section 4. Icon Map AI runs on the user's own machine, reads data as the signed-in user and stores nothing with Tekantis (section 10).

What does Tekantis hold, then? Operational data only: account and contact details, license and usage records (identifiers and counts), trial and upgrade requests, data store orders, and delivery records that name where a copy was written but never its content. It is held in UK South, with contact records in HubSpot. See section 12.

Does Tekantis ever delete anything from our OneLake? No. When a data store license ends, you are asked to stop using the copy and delete it yourself (section 12.3).

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.

Does Icon Map AI send our data to Tekantis or to an AI model? Not to Tekantis: the MCP server runs on the user's machine, reads Fabric data as the signed-in user, contains no AI model, and sends Tekantis nothing beyond a license check, usage records and catalog search terms. What it returns to the AI assistant - bounded data samples, column statistics and preview images - is seen by the model your organization connected to that assistant, under that provider's terms, and never exceeds what the user could already read. See section 10.

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. The separate user-owns-data mode has nothing to disable in the same sense - it only ever shows a signed-in viewer data they already have Fabric permission to, so removing that permission removes their access.

We want to embed a map in our own internal app - do our viewers see everyone's data? No. In the user-owns-data mode each viewer signs in with their own Entra identity and the map reads as them, so your existing Fabric and Power BI row-level security applies per viewer automatically. There is no service principal, no published copy, and no filter mapping for us to get wrong. See section 4.

How is the anonymous embed surface secured? A publish can never grant more access than its author already has (verified under the author's identity at publish time), published content is cryptographically signed and verified on every read so tampered maps are refused, the embed service reads under a dedicated read-only service principal scoped to just the Lakehouse holding your published maps (or your own service principal, if you prefer), credentials never reach viewers, and token-gated embeds can be restricted to your own site origins. Revocation takes effect within 30 seconds. See section 4.

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 embed reader used for published maps; it requests no API permissions and holds only a read-only data-access role on the Lakehouse that stores your published output, granted automatically at publish and removable at any time. Enterprises can supply their own service principal for this read, or self-host the embed service so no Tekantis identity is in the data path at all. Icon Map Desktop and Icon Map AI likewise sign in as the user (sections 9 and 10).

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. Icon Map AI sends no analytics telemetry, only usage records for licensing. See section 12.5.

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.
• AI map authoring - what Icon Map AI does, for authors.