Data Collection
+Last updated: {LAST_UPDATED}
- This service collects and processes the following data to provide monitoring functionality: -
--
-
- Device hardware information (manufacturer, model, serial number) -
- Autopilot provisioning session data (status, events, timestamps) -
- Azure AD/Entra ID tenant information -
- User authentication information (UPN, display name, tenant ID) -
- Operational telemetry and audit logs -
- Anonymized usage telemetry (via Azure Application Insights, no cookies) — used to understand which features are used and improve the service. No personal data is transmitted. -
Data Processing Context
-- During an Autopilot enrollment, the user authenticates solely to verify their identity and initiate the process. - After that, the user is not actively interacting with the device while provisioning runs. As a result, the data - collected by the monitoring agent consists exclusively of technical enrollment events — no user - activity, browsing data, or personal content is captured. -
-- Tenant administrators retain full control over collected data through the following options: -
--
-
- Data Retention — configurable retention period per tenant (default 90 days); expired sessions are automatically purged -
- Delete Session — delete individual monitoring sessions on demand -
- Offboard Tenant — remove all data and configurations for a tenant from the service -
- These controls ensure that no personal information accumulates in the backend beyond what is necessary for
- enrollment monitoring. The service is designed for operational transparency, not user surveillance.
+ Autopilot Monitor collects technical telemetry about Windows Autopilot enrollments so that IT teams can see
+ what happened during a device provisioning and why it failed. This policy explains what is collected, where it
+ is stored, who can reach it, and how long it is kept. The technical detail behind every statement here is
+ published in the
Data Storage & Security
+Roles: Who Is Responsible for What
- The platform is built with a layered security architecture designed to protect data at every level: + For enrollment telemetry, your organization is the controller and Autopilot Monitor acts as your + processor. You decide which devices are monitored, what additional data your gather rules collect, + how long it is retained, and when it is deleted. +
++ For operating the service itself — administrator accounts, the audit trail of portal actions, and operational + telemetry — glueckkanja AG is the controller. +
++ glueckkanja AG, a German company certified to ISO/IEC 27001, operates Autopilot Monitor for{" "} + both plans — the same service, the same infrastructure, the same protection measures. Company + details are in the Imprint. + The project is maintained by Oliver Kieselbach, who acts in that role on behalf of glueckkanja AG and is the + contact for the open-source project and the Community edition. +
++ A data processing agreement (DPA / AVV) is available on request, concluded with + glueckkanja AG. On the Enterprise plan it forms part of the written agreement.
-Authentication & Device Identity
+What We Collect
+From enrolling devices
-
-
- Device agents authenticate via Intune MDM client certificates, validated against the embedded Intune CA chain -
- Web users authenticate via Microsoft Entra ID (Azure AD) with multi-tenant JWT validation -
- Autopilot device validation via Microsoft Graph — only registered Autopilot devices are accepted -
- Optional hardware whitelist for additional device verification -
- Per-device rate limiting (sliding window) to prevent abuse +
- Device identity — serial number, device name, manufacturer, model, and the Entra ID tenant the device enrolls into +
- Enrollment progress — phases, ESP stages, application and script results, policy activity, reboots, timings, and failure codes +
- Device context — OS build, hardware characteristics, disk and network state, plus whatever your own gather rules request +
- Approximate location — country, region, city, and approximate coordinates, if geolocation is enabled for your tenant
Tenant Isolation
+From portal users
-
-
- Strict multi-tenant data isolation — all storage queries are partitioned by Tenant ID -
- Real-time channels (SignalR) are scoped to tenant-specific groups -
- Independent configuration, audit logs, and device management per tenant +
- Sign-in identity from Microsoft Entra ID — user principal name, display name, and tenant ID +
- Audit records of administrative actions, including who performed them and when +
- Operational request telemetry used to run and support the service
Transport & Data Protection
--
-
- All communication encrypted via HTTPS/TLS; real-time updates via secure WebSocket -
- Diagnostics upload URLs are issued on-demand, and never persisted on the device -
- Azure Storage encryption at rest for all persisted data -
- PII logging disabled in production environments -
Access Control
--
-
- Role-based access: Tenant Admin (full tenant management), Operator, Users -
- Device blocking capabilities for compromised or unauthorized devices -
- Comprehensive audit logging of administrative actions -
Data Sharing
+What We Do Not Collect
- Your data is not shared with third parties. Access is restricted to: + During Autopilot provisioning the user signs in once to start the process and then does not interact with the + device while it provisions. The agent captures no browsing history, no file or document content, no + keystrokes, no screen content, and no application usage tracking. It removes itself when enrollment + finishes. The service is designed for operational transparency, not user surveillance. +
+
+ Gather rules cannot be used to widen this: C:\Users{" "}
+ is always blocked for privacy reasons, and downloading files, creating users, manipulating boot configuration,
+ and establishing persistence are hard-blocked and cannot be enabled by configuration.
+
IP Addresses and Geolocation
++ Geolocation is a tenant setting and is enabled by default. While it is enabled:
-
-
- Authenticated users within your tenant -
- Global Administrators (for platform operations and support) +
- The session record stores only the derived location — country, region, city, and approximate coordinates. The IP is deliberately excluded from the location event shown in the timeline. +
- The outbound public IP is additionally stored once per session as a separate diagnostic event. It is hidden from the timeline view by default, but it is retained and queryable, and it expires with your retention period like any other event. +
- Service request telemetry does not carry device IP addresses; the platform masks them and the application never sets them. +
- A source IP is also stored on distress reports — the emergency channel an agent uses to report that it is failing — as part of that incident record. +
+ Disabling geolocation stops all of this — no IP and no location data is collected. It is a + tenant setting and also an agent command-line switch. Only the Geographic Performance view is affected. +
+ +Where Your Data Is Stored
++ All customer data — sessions, events, configuration, audit logs, diagnostics, and backups — is stored in + Microsoft Azure in Germany West Central. The only component outside that region is the portal + front-end, served as static assets from West Europe; it stores no customer data. There is no cross-region + replication and no transfer of customer data outside the EU by the platform. +
+ +Who Can Access Your Data
++ Your data is not sold, and it is not shared with third parties for their own purposes. Access is limited to: +
+-
+
- Authenticated users in your own tenant, according to their role — Admin, Operator, Viewer, or a role-less Member limited to the Progress Portal +
- Platform operators — Global Admin for operations and support, and Global Reader for read-only support with configuration secrets redacted +
- Delegated (MSP) administrators you or your provider have been granted — read-only, limited to exactly the tenants in scope, with configuration secrets redacted, and with every grant and revocation written to your tenant's audit log so you can always see who was given access to your data +
+ Delegated administration is an Enterprise capability and is off unless explicitly granted. Full detail on the
+ isolation model is in the
Sub-processors and Outbound Data Flows
++ Microsoft Azure is the only sub-processor that stores your data. Resend is used solely to + deliver the onboarding approval email when a tenant is activated — it receives an administrator's email + address and the tenant domain, never enrollment telemetry. Vulnerability reference data is pulled inbound from + NVD, the CISA KEV catalog, and MSRC; no customer data is sent to them. +
+
+ Some data flows exist only because you configure them: your own Azure storage account for diagnostics,
+ notification channels such as Teams, Slack, or a generic webhook, and your own AI assistant if a user connects
+ one through the MCP integration. The platform itself makes no calls to any AI or LLM provider. The complete
+ list is published as
Diagnostics Uploads
++ Diagnostics upload is off by default. When enabled, the default destination is{" "} + your own Azure storage account — the package never reaches our infrastructure. Hosted upload + exists as an alternative but is opt-in only and requires an explicit administrator action behind a clearly + marked disclosure that data leaves your tenant. It is never enabled silently. +
+ +How Long We Keep Data
++ Retention is configured by you per tenant, defaulting to 90 days — 7 to 90 days on the + Community plan and 7 to 365 days on Enterprise. Expired sessions are purged automatically. You additionally + control: +
+-
+
- Delete session — remove an individual monitoring session on demand +
- Offboard tenant — remove your tenant's data and configuration from the service entirely, as a verified multi-phase cascade +
+ Two things intentionally survive tenant offboarding, neither of which contains enrollment telemetry or + personal data: +
+-
+
- Product feedback you submitted — it is not tied to enrollment data and is what improves the product. +
- Custom rules and IME log patterns you authored are archived rather than deleted. Detection knowledge is what makes this product useful, so contributed rules and patterns are subject to entering the community pool — the next organization hitting the same enrollment failure gets a diagnosis instead of a mystery. A rule is a detection definition, not device data. +
+ Either can be removed on request. +
+ +How Your Data Is Protected
+-
+
- Device authentication by mutual TLS using the Intune MDM client certificate, validated against pinned Intune root CAs rather than the operating system trust store — and rejected if no trust anchor loads +
- Autopilot device validation via Microsoft Graph — only devices registered in your tenant are accepted, with an optional hardware allow-list on top +
- Entra ID authentication for portal users with a restricted signing-algorithm allow-list and identity PII logging disabled +
- Fail-closed authorization — every API route must be registered with an access policy; an unregistered route is unreachable +
- Structural tenant isolation — storage partitioning by tenant, with the tenant identity taken from the validated token and never from a client-supplied header +
- Encryption — HTTPS with a TLS 1.2 floor in transit, Azure Storage encryption at rest with platform-managed keys +
- Managed identity instead of storage keys, and secret-less OIDC deployment pipelines +
- Rate limiting per device, per portal user, and per MCP user +
- Verifiable agent binaries — Sigstore build attestation plus a four-stage integrity chain through download, backend cross-check, and runtime self-verification +
- Manifest-first deletion — what will be deleted is captured, restorably, before anything is removed
Your Rights
- As this is an environment operated under best-effort principles, formal data subject rights (access, deletion, portability) - are not guaranteed. However, we will make reasonable efforts to accommodate such requests on a case-by-case basis. + Where the GDPR applies, you have the right to access, correction, deletion, restriction of processing, + portability, and to object to processing. We act on such requests within the statutory time limits. In + practice most requests resolve immediately in the portal, because deletion of individual sessions, full tenant + offboarding, and the retention period are all controls you hold yourself. +
++ Where Autopilot Monitor acts as your processor, requests from your own employees should be directed to your + organization; we support you in fulfilling them. +
+ +Changes to This Policy
++ Material changes are reflected in the "last updated" date above and announced through the service + announcements in the portal. If you hold a signed data processing agreement, notification follows the terms of + that agreement. +
+ +Contact
++ For privacy questions, a data processing agreement, or a data subject request, contact glueckkanja AG using + the details in the Imprint. + For the open-source project and the Community edition you can also reach the maintainer via{" "} + LinkedIn{" "} + or open a{" "} + GitHub issue.