Legal

Privacy Policy

Last updated: 23 August 2026

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 Security & Privacy FAQ.

Roles: Who Is Responsible for What

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 Pro plan it forms part of the written agreement.

What We Collect

From enrolling devices

  • 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

From portal users

  • 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
  • Content you choose to enter about a session — report comments and annotations (a verdict on the analysis plus notes) — stored with your tenant's data and attributed to the author
  • Operational request telemetry used to run and support the service
  • A contact address for your tenant, if one is provided

The contact address is used only to reach you about this service — a technical problem affecting your tenant, a security matter, or a change that needs an administrator's attention. It is never used for marketing and never shared. Your administrators set and change it under Settings → Tenant → Contact, and clearing it removes it. Where an organization gave a notification address during sign-up (tenant activation), that address is copied once as the initial contact and is yours to change from then on.

What We Do Not Collect

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:

  • 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 a Pro capability and is off unless explicitly granted. Full detail on the isolation model is in the Security & Privacy FAQ.

External Services

Microsoft Azure is the only place your data is stored. Mailchimp Transactional (Mandrill) delivers the welcome email when a tenant is activated and the farewell email after offboarding — it receives an administrator's email address and the tenant domain, never enrollment telemetry; open and click tracking is disabled. Vulnerability reference data is read inbound from NVD, the CISA KEV catalog, and MSRC; nothing about your environment is sent to them.

Further connections exist only because you configure them: your own Azure storage account for diagnostics, notification channels such as Teams, Slack, Discord, 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. Data Flows & External Services maps every outbound connection and what it carries. The data processing agreement, available on request, is the authoritative document for the parties engaged and the terms of their engagement.

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 — in Settings, or in the one-step dialog offered on a session — always behind a clearly marked disclosure that data leaves your tenant. It is never enabled silently. One explicit exception: when an administrator submits a session report for analysis and chooses to include the session's uploaded diagnostics archive, a copy of that package is stored with the report so it remains available for the investigation.

Once upload is configured, an Admin or Operator in your own tenant can also request a package on demand from an enrollment that is still running, instead of waiting for it to finish. It collects exactly what the automatic package collects — the configured paths, nothing wider — the device only acts on the request when the agent next checks in, and both the request and its outcome appear as events on that session's timeline. Viewers and Progress-Portal members cannot trigger it, and it does nothing on a tenant that has no upload destination configured.

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 Pro. 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
  • Device registration validation via Microsoft Graph — only devices your tenant actually knows are accepted (Windows Autopilot registration, corporate device identifiers, or the Windows 365 Cloud PC inventory), 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

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.