Privacy

This page describes the technical reality of what CloudSergeant sends, stores and never touches. It is written to be checkable, not reassuring.

This page covers the technical data flows. The formal legal terms and data-processing documentation are being finalised for launch — see Terms.

The principle

CloudSergeant is a tool you point at your own tenant and, if you are a partner, at your customers' tenants. Directory, OneDrive and mailbox data stays off our servers by design. There is one narrow identity-protocol exception: after a customer Global Administrator approves a copied consent link, Microsoft returns that browser through our website with the customer tenant id. The callback discards it immediately as described below.

Directory, OneDrive and mailbox traffic goes from your machine directly to Microsoft. Our service exists to answer two questions: is this organisation's licence valid, and is there a newer version of the app.

What is sent to us

Four values, on a licence check that happens at most once every 24 hours (or when you press Check licence status):

ValueWhy
Your own Microsoft tenant id A licence covers an organisation, so we have to know which organisation is asking. This is your tenant — never a customer's.
The signing-in administrator's identity, from the Microsoft token Read from the validated token to confirm the request is genuine. It is not stored against your licence record.
The version of the app To answer whether an update exists and whether it is required.
An opaque installation id A random identifier generated on first run. It contains no user, machine, organisation or network information, and is used only to count installations against a licence.

Before that check, and before you sign in, the app may ask anonymously whether a newer version exists. That request carries the version and nothing else.

Downloading the app records that a download happened, so we can tell how a release is being taken up.

The admin-consent callback

If a partner sends a copied consent link to a customer's Global Administrator, Microsoft redirects that administrator to our /consent/complete page afterwards. Its standard response includes the customer tenant id and whether approval succeeded. We read only the approval or error flag, immediately redirect to a clean result page, and do not read, display, persist or application-log the tenant id. The result page is informational; the desktop independently verifies consent with Microsoft before using it.

What is never sent

These are not "not currently collected" — the app has no code path that transmits them, and the server has nowhere to put them:

  • A customer tenant's name, customer list or directory data. Your customer list is fetched from Microsoft, not from us, and never reported back. The one transient tenant-id callback from Microsoft is described above.
  • Any mailbox address, of yours or anyone else's.
  • Any message — subject, body, sender, recipient or attachment.
  • Any folder name.
  • Any count derived from your data — not how many mailboxes you have, how many messages a run matched, or how large they were.
  • The result of any operation. We do not know what you did, to what, or whether it worked.
  • Any user, group, device or contact from any tenant.
  • Your activity log. It never leaves your machine.

There is also no telemetry, no analytics SDK, no crash reporter and no usage tracking in the desktop app. When something fails, the detail is written to a local file for you to read.

What goes to Microsoft

Everything the app actually does. Sign-in goes to Microsoft Entra; directory, OneDrive and mailbox operations go to Microsoft Graph, SharePoint Online and Exchange Online, in your tenant or the customer tenant you have switched into.

All of it is delegated — carried out with a token issued for you, so it appears in Microsoft's own audit log attributed to your account, and is governed by your organisation's Conditional Access policies. There is no application permission, no service account and no path by which CloudSergeant can act when nobody is signed in.

Microsoft's handling of that data is covered by your existing agreement with Microsoft. We are not a party to it and we do not receive a copy of any of it.

What is stored on your machine

All of your data under %LocalAppData%\CloudSergeant\, in your own Windows profile:

FileContents
msal.cacheMicrosoft sign-in tokens, encrypted by Microsoft's own library for your Windows account. This is what makes relaunch silent.
device.idThe opaque installation id described above.
entitlement-*.binThe licence answer, encrypted with Windows DPAPI for your user account and bound to the tenant and installation.
window.jsonWindow position and size.
logs\The activity log, described below. Files older than 90 days are deleted automatically.
updates\An installer you chose to download, kept only until it runs. It contains no data about you or your customers.

The application itself is installed outside that folder — under %LocalAppData%\Programs\CloudSergeant by default — alongside one registry value recording where it went. Neither holds any data about you, your organisation or your customers. Uninstalling removes them and leaves the files above in place.

A second sign-in used to reach someone else's mailbox is deliberately not cached: those tokens are held in memory only and dropped when you sign out, switch tenant or start over.

You can remove everything by deleting that folder, and clear the sign-in tokens from inside the app with Account ▸ Clear cached tokens.

The activity log

One text file per day recording sign-ins, every change made to a tenant, every tool run, and the full technical detail of every error. It is for you and your auditors; it is never transmitted.

It is written to avoid capturing mail content even locally:

  • A change records the names of the fields that changed, not their values.
  • A tool run records a start line and an end line with counts — never a line per message, because that line would carry the message's subject.
  • A password is never recorded, only that one was reset. A BitLocker recovery key is never recorded, only that one was revealed.
  • A file path is recorded by filename only, since the folders around it can name a customer.

The deliberate exceptions are the identity of an object being changed and of a principal being granted access — without those, "who was given access to whose mailbox" would be unanswerable, which would make the log useless for the purpose it exists for.

This website

These pages are static HTML and CSS. There are no cookies, no analytics, no tag managers, no advertising or social pixels, and no third-party fonts, scripts or images — everything is served from this domain. Nothing here tries to identify you.

One small script asks our own API for the current version number so the download card can show it. Like any web server, ours records requests — including IP address, time and user agent — for security and operational purposes.

The admin-consent callback is handled differently: application-level request logging that could include its query string is disabled, its response is not cached or indexed, and it redirects immediately to a URL containing no tenant information.

Subscription management

Signing in to manage a subscription uses Microsoft Entra. It sets one encrypted session cookie, which is strictly necessary for signing in and is not used for tracking.

Registering an organisation stores your Microsoft tenant id, the company name, billing address and contact email address you type, and the time and version of the terms you accepted. All of those are entered explicitly: the company name is never inferred from a person's name, and the address and contact email are used for licence and invoicing correspondence about your own organisation only.

Checking this yourself

You do not have to take our word for it. The app talks to exactly one host of ours, cloudsergeant.com, and everything else it contacts belongs to Microsoft — so a network trace, a proxy log or a firewall rule will show you the whole picture. The licence request is small and infrequent by design, and blocking our host entirely leaves the app working until its offline window expires.

Questions about any of this, or about data processing for a specific engagement, are welcome — see Terms for how to reach us.