EntraGUARD

About this guide

This document describes how to use EntraGUARD end to end, from installation through to producing an audit report you can hand over to a client. It covers installation, license activation, how the application name and reports work, connecting to the audited tenant, control selection, baselines and compliance frameworks, running audits, reading the results and exporting reports.

Who this guide is for

• Auditors and consultants running Microsoft 365 / Entra ID configuration audits for their clients.
• In-house security teams (CISO, IAM, SecOps) tracking the posture of their own tenant over time.
• MSPs and resellers operating the application under their own brand across a portfolio of clients.
• Administrators of the audited tenant, for the connection and permissions part only (chapter 6).

Documented version

1. Introduction

1.1 What EntraGUARD is

EntraGUARD is a Windows desktop application that audits the security configuration of a Microsoft Entra ID tenant and its associated Microsoft 365 services. It queries the Microsoft APIs read-only, compares the live configuration against a catalog of 323 control points drawn from recognized public frameworks, and produces a compliance score, a control-by-control breakdown and exportable reports.

The idea is simple. A manual audit means walking through dozens of screens across the Entra portal, the Microsoft 365 admin center, Defender, Purview and Exchange Online, noting the gaps in a spreadsheet. EntraGUARD covers the same ground in about fifteen seconds, repeatably, and keeps the history so you can measure progress.

1.2 Design principles

1.3 What EntraGUARD does not do

• It does not remediate. No automatic fixes, no changes to the tenant. The PowerShell commands provided are informational, to be run knowingly by an administrator.
• It does not monitor continuously. An audit is a manual, point-in-time run — a snapshot of the configuration, not a SIEM or a detection tool.
• It does not audit Active Directory or Azure. Those scopes are covered by AdGUARD and AzureGUARD, built on the same foundation.
• It does not analyze content. The application reads configuration settings and directory object metadata, never the contents of mailboxes, files or conversations.
• It does not replace a human audit. It industrializes the mechanical, repeatable part so you can spend your time on analysis, context and recommendations.

1.4 Functional architecture

The application is built on five components:

1. The connectors establish read access to the Microsoft APIs (Microsoft Graph for Entra ID, SharePoint, OneDrive, Teams, Defender, Intune and Purview; Exchange Online Management for mail).
2. The control catalog describes what to check: 323 control points grouped into 13 packs, each tied to a referential, a category, a criticality level and a set of framework mappings.
3. Baselines define the scope retained for a given engagement: which controls are in scope, which are excluded, and at what criticality level.
4. The audit engine runs the selected controls in parallel, assigns a verdict to each and computes a weighted score.
5. Reports present the outcome from four editorial angles (executive, technical, action plan, regulatory compliance) and in five file formats.

1.5 Terminology

2. Installation and first run

2.1 Requirements

2.2 Installation

The application ships as a standard Windows installer (EntraGUARD-Setup-0.1.0.exe, built with Inno Setup):

1. Run the installer with a local administrator account.
2. It installs to C:\Program Files\EntraGUARD for all users of the workstation.
3. A Start menu shortcut is created; a desktop shortcut is offered as an option.
4. On first launch, the application creates its shared data area (§ 2.3).

Later updates install over the top: the application ID is stable, so the installed version is detected and replaced. Data — client records, history, connectors, license — is never touched by a reinstall, because it lives outside the program folder.

2.3 Where the data lives

All data sits under a single root, shared across every Windows account on the machine. That is a deliberate choice: on a shared audit workstation, two consultants must find the same clients and the same history.

C:\ProgramData\EntraGUARD\
├── license.key                  installed license key (shared by the whole machine)
├── control-packs\               imported control packs (JSON)
├── connector-packs\             imported connector packs (JSON)
└── clients\
    ├── <client-1>\
    │   ├── settings.json        connectors, export, branding, performance
    │   └── audit.db             SQLite database: history and detailed results
    └── <client-2>\
        └── ...

HKCU\Software\EntraGUARD\ActiveClient   selected client (per Windows session)

If the application previously ran in a version that stored data in the user profile (%AppData%\EntraGUARD), the contents are copied — not moved — to the new root on first launch. The old folder stays in place as a backup.

2.4 First run

Getting started takes six steps:

1. Activate the license — Settings › License, paste the key you were given (§ 3.3).
2. Create the first tenant — Tenants › Add a tenant, filling in at least the name and the tenant domain (§ 5.2). The application name itself comes from your license (§ 4).
3. Create the first company — Companies › Add a company, filling in at least the name and the tenant domain (§ 5.2).
4. Connect the tenant — Settings › Connectors, configure Entra ID using one of the two scenarios in chapter 6, then enable the Microsoft 365 connectors you need.
5. Choose the scope — Baselines › Templates to start from a compliance framework, or Security controls to pick manually (§ 7.4 and § 9).
6. Run the first audit — Security audit › Execution, then export the report (§ 10 and § 13).

2.5 The interface

The application has three areas: a collapsible sidebar on the left, the active view in the center, and in the top right the theme selector (light / dark) and the language selector (EN / FR). The name shown at the top of the sidebar is the license holder's name, carried by the license (§ 4).

The sidebar is organized as follows:

3. License and activation

3.1 How it works

The license is verified entirely offline, using an asymmetric ECDSA signature on the P-256 curve (SHA-256 digest). The vendor signs the license content with a private key that never leaves their machine; the application embeds the matching public key, which can only verify a signature, never produce one. Decompiling the application therefore does not allow anyone to forge a license, and there is no activation server to reach.

The license file is a block of text wrapped in a readable armor, in the manner of a PEM key:

-----BEGIN GUARD LICENCE-----
...signed content, base64url-encoded...
-----END GUARD LICENCE-----

The signed content carries the following fields:

3.2 Where licenses come from: the GuardLicence application

Licenses are no longer produced by a generator built into the application, as was the case in earlier versions. They are issued by a dedicated application, GuardLicence, held by the vendor and, where applicable, by authorized partners.

GuardLicence holds the signing authority and works as a three-level chain:

• a root (the vendor's private key) signs certificates;
• each certificate authorizes the issuance of bounded licenses: allowed products (EntraGUARD, AdGUARD, AzureGUARD), tenant cap, expiry date;
• from a certificate, individual licenses are issued for each client.

This model lets the vendor delegate issuance to a partner without handing over the root: the partner can only issue within the limits written into their certificate. The EntraGUARD application itself knows only the root public key and merely verifies the license it receives.

3.3 Activating a license

Open Settings › License. Two options, depending on how the license was delivered:

• Paste the key: paste the full license text, armor included, into the field, then confirm.
• Load a file: select the supplied license.key file; its content is read and installed.

On activation, the application checks in turn the signature (the license is authentic and untampered), the product (it is indeed an EntraGUARD license), the expiry and the tenant cap. It then shows the license state, the holder's name, the expiry date and the number of tenants allowed.

3.4 The four states

The state is determined when the license is loaded, then re-evaluated against the date: a valid license switches automatically to Expired on its expiry day.

3.5 The tenant quota

The license sets a maximum number of tenant records. When that cap is reached, adding a new tenant is refused, with a message stating the current limit and the number of records already created. To audit more tenants, activate a license with a higher cap. Deleting an existing record frees a slot in the quota.

3.6 Renewal and deployment

Renewing simply means activating a new license with a later expiry: it replaces the previous one, with no other steps. To deploy the same license on several machines, distribute the same license.key file and activate it on each; the license is not tied to a particular machine. On a shared machine, the installed license applies to all Windows accounts.

4. Application name and reports

4.1 The name comes from the license

The Settings › Branding menu from previous versions, which let you set an application name, tagline and logo along with an issuer identity, has been removed. The name the application displays — on the splash screen, in the title bar and at the top of the sidebar — is now the license holder's name, as written in the license.

This name is no longer editable by hand: it applies as soon as a license is activated. Until a license is loaded, the application is called "EntraGUARD".

4.2 Identity in reports

Exported reports (HTML, PDF) carry the license holder's name — that is, the application name — together with the generation date, in the header and footer. The detailed issuer customization that existed before (company, website, contact address, header logo, all set in Settings › Branding) is no longer offered: the issuer's identity in reports is limited to the name carried by the license.

In concrete terms, a report footer shows the holder's name and the date, once, with no duplicate.

4.3 The audited tenant's logo

The audited tenant's logo, by contrast, is still fully supported — this is a notion distinct from the issuer's identity. From a tenant record (§ 5.2) you can attach a logo: it appears on the cover page of that tenant's executive report. This is the audited client's logo, on their own report.

Aim for a crisp image, around 180 px tall, on a transparent or white background, in PNG or JPG. This logo is specific to each record: two tenants can each have their own.

4.4 Theme and language

The application offers a light and a dark theme, as well as a switch between French and English. These settings are available in the preferences and apply immediately across the whole interface, with no restart. They are independent of the license and specific to each machine.

5. Managing audited companies

5.1 The portfolio

The Companies screen lists every tenant you follow, with four headline figures: number of companies, number of audits run, number of companies never audited, and the date of the most recent audit across all clients. A search box filters the list, and Add a company creates a new record.

For each company the list shows its domain, contact, industry and country, plus two sortable posture columns: the date of the last audit (or "Never" in italics) and the score obtained, colored by band, with the point difference against the previous audit. A CSV export of the whole portfolio is available from the list header.

5.2 The company record

Company record block — the client's details:

5.3 Activity

The Activity block of the record summarizes the client's posture: number of audits run, date and score of the last audit with its delta, overall score, number of configured connectors, the compliant / warning / non-compliant split of the last audit, and the list of referentials actually audited. This is the view to open before a client meeting: ten seconds and you know where things stand.

5.4 The active company and data separation

At any moment exactly one company is active. It appears at the top of the sidebar and drives everything else: the connectors shown, the baselines available, the history consulted, the dashboard and the reports produced all belong to that company. Switching happens on the fly from the list, with no restart.

Each company has its own folder on disk, with its own settings (settings.json) and its own history database (audit.db). One client's tenant credentials are therefore never reachable from another client's context.

6. Connectors: connecting the audited tenant

6.1 Overview

Connectors are the technical entry point of the audit. Each one opens read access to a data source; an unconfigured connector locks every control in its referential, which are then excluded from scope and do not count toward the score.

A connector's possible states are Configured or Not configured for Entra ID, and Enabled or Disabled for the connectors that depend on it.

6.2 The two deployment models

Everything rests on a registered application in the client's tenant, holding read-only application permissions. There are two routes to that application, and choosing between them is above all a question of the client's internal policy, not of technical capability.

6.3 Scenario A — the audited company supplies the application

This is the scenario to favor with clients whose security policy forbids a supplier from handling an administrator account, or who insist on keeping control over the permissions granted.

On the client side, the tenant administrator:

1. Creates an application in Entra ID › App registrations (any name, for example "Security audit — <your company>").
2. Adds the application permissions for Microsoft Graph listed in § 6.9, all read-only.
3. Grants admin consent for those permissions.
4. Generates a client secret, or uploads a certificate whose thumbprint will be shared.
5. Sends the tenant ID, the application ID and the secret (or thumbprint) over a secure channel.

On the auditor side, in Settings › Connectors › Microsoft Entra ID:

1. Choose the Use an existing application mode.
2. Enter the tenant ID and the application ID.
3. Provide either the client secret, or the thumbprint of a certificate already present in the workstation's Windows store.
4. Click Test and connect.

The test validates two things in turn: that a token can be obtained (the credentials are right), then that a real call to Microsoft Graph succeeds (the permissions were actually granted). Successful authentication followed by an access denial means the application was created correctly but its permissions are incomplete or admin consent was never given — the error message then reports the HTTP status returned.

6.4 Scenario B — automatic provisioning, with an administrator present

Here the application does all the work. The tenant administrator signs in once, interactively, and the application chains creation and configuration together.

Steps in Settings › Connectors › Microsoft Entra ID:

1. Choose the Create the application mode.
2. Enter the name for the app registration ("EntraGUARD" by default).
3. Choose the authentication method: certificate (self-signed, placed in the machine store — the application must then be run as administrator) or client secret (generated by Entra, valid for two years, shown only once).
4. Click Create the application: a Microsoft sign-in window opens and the administrator authenticates.
5. The application creates the app registration, attaches the certificate or secret, grants the application permissions and admin consent, then chains the Exchange configuration automatically (§ 6.7).

The operation takes up to a minute, allowing for replication on the Azure side. The delegated permissions requested from the administrator during that phase, and only during that phase, are Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All and Directory.Read.All. They exist to create the application and grant it its rights; the audit itself then uses only the read-only application permissions.

6.5 Choosing between the two scenarios

6.6 The Microsoft 365 connectors

Once the Entra ID connector is configured, the SharePoint, OneDrive, Teams, Defender and Intune connectors are enabled with a single toggle: they reuse the same application and the same Graph permissions. Each has a Test connection button.

6.7 Exchange Online and Purview

Exchange Online is a special case: its app-only API requires certificate authentication, a client secret is not enough. Three things must be in place in the tenant:

1. A certificate attached to the Entra application.
2. The Exchange.ManageAsApp application permission, held by the "Office 365 Exchange Online" resource rather than by Microsoft Graph.
3. The Global Reader directory role assigned to the application's service principal.

In scenario B these three steps are chained automatically after the application is created, and the application switches from a secret to a certificate if needed. In scenario A they must be requested explicitly from the client, failing which the Exchange connector stays unreachable even though Entra ID works perfectly.

The Purview connector reuses the certificate set up for Exchange: if Exchange works, Purview enables itself with no further configuration.

6.8 Test, remove, delete

Three distinct actions, not to be confused:

6.9 Required permissions

This is the table to hand to the client in scenario A. All of these are read-only application permissions. No write permission is requested, or used.

On top of that, for Exchange and Purview only, the Global Reader directory role must be assigned to the application's service principal. It is a read role: it allows no changes.

6.10 Security of stored credentials

Secrets kept on the workstation (the Entra client secret, connector secrets) are encrypted with DPAPI at machine scope. In practice:

• A configuration file copied to another machine is unreadable.
• Every Windows account on the workstation can decrypt the secrets: that is deliberate, since they share the same audit machine and the same connectors.
• Confidentiality against another user of the same workstation is therefore not a goal of the model. An audit workstation should be treated as a sensitive asset and protected accordingly: disk encryption, restricted access, locked session.

7. Controls and referentials

7.1 The catalog

Version 0.1.0 ships 323 controls across 13 built-in packs, compiled into the application itself: no JSON file is distributed alongside the executable, and the catalog is available from the very first launch.

By referential: Entra ID 136, Exchange 69, Teams 28, Intune 23, Defender 22, SharePoint 19, Purview 17, OneDrive 9.

7.2 Anatomy of a control

Every control carries the following, all of which appear in the interface and in exports:

7.3 Levels L1 and L2

This weighting is structural: missing an L1 control costs three times as much as an L2. It prevents a tenant that has neglected MFA but enabled a pile of cosmetic hardening measures from posting a flattering score.

7.4 Selecting controls

The Security controls section of the sidebar has one entry per referential whose connector is configured. Each screen groups controls by category, with a toggle per control and All / None actions at category level, plus Select all / Deselect all at the top. A "X / Y controls selected" counter always shows the scope retained.

7.5 Adding your own controls

The Settings › New control screen extends the catalog without reinstalling the application, by importing control packs in JSON. Two routes: by URL (an internal share or a public address) or by file import.

Imported packs are merged into the built-in catalog. A restart is needed to load them into the audit referentials — the application offers to do it. Built-in packs are part of the application and cannot be deleted; only imported packs can be removed.

This is the mechanism to use for organization-specific requirements: an in-house policy, a recurring contractual clause, or a control demanded by an external auditor.

8. Compliance frameworks

8.1 The mapping principle

Every control in the catalog is cross-referenced to the frameworks it answers to. That cross-referencing is not decorative: it is what allows an "ANSSI" or "CIS level 1" baseline to be produced without retyping anything, and a compliance-by-framework report to be generated. The mappings appear in each control's detail and in every export format.

8.2 Coverage

8.3 Use in engagements

• Preparing for ISO 27001 certification — the ISO A.5 and A.8 templates isolate the organizational and technological measures that apply to the Microsoft 365 scope.
• NIS2 or DORA compliance work — the whole catalog is mapped; the value here is the compliance-by-framework report, which speaks the regulator's language.
• A French-context audit — the ANSSI template narrows scope to the 89 controls aligned with the agency's recommendations.
• Progressive hardening — the CIS level 1 template is a first pass that applies without heavy negotiation; level 2 follows later.
• US federal agencies and their suppliers — the CISA SCuBA and NIST 800-171/CMMC templates address those specific requirements.

9. Baselines

9.1 What a baseline is

A baseline is the agreed audit scope: the list of controls retained, those set aside, and any level adjustments. It is the object that makes an audit repeatable and defensible — without one, the question "why was this control not assessed?" has no documented answer.

A baseline is defined by:

• A name, shown on every audit run with it and in the history.
• A scope: global (available to every company) or specific to one client.
• A free-text description, where the reasons for exclusions are recorded.
• The list of controls included, excluded and re-levelled.

9.2 The templates provided

Seventeen templates are offered. Each selects the controls matching a compliance criterion and excludes the rest. The counts shown are computed from the real catalog, never hard-coded: they follow automatically as controls are added.

9.3 Creating a baseline from a template

1. Open Baselines › Templates.
2. Find the template matching the engagement and check the runnable count.
3. Click Create a baseline: the editor opens with the selection pre-applied.
4. Name the baseline, choose its scope, adjust if needed, then Save.

9.4 The baseline editor

9.5 Global or client scope

9.6 Good practice

• Start from a template rather than the full selection: a template carries a compliance rationale the client understands.
• Exclude controls that are technically out of scope — typically those requiring an Entra ID P2 or E5 license the client does not have. A non-applicable control assessed as non-compliant drags the score down without carrying information.
• Document every exclusion in the description: at debrief time, that is what separates a deliberate scope from an oversight.
• Keep a frozen global reference baseline, so progress over time is measured on a constant basis.
• Do not change a baseline mid-engagement: an audit run on a different scope is no longer comparable to the previous one.

10. Running an audit

10.1 Preparation

Three checks before starting:

1. The active company is the one you expect (top of the sidebar).
2. The connectors you need are configured and tested.
3. The scope is settled: a baseline applied, or a manual selection confirmed.

10.2 Starting and following the run

The Security audit › Execution screen shows the retained scope at the top as "X / 323 controls enabled", then the Start security audit button.

During the run:

• A dial shows overall completion as a percentage and an "n / N" count.
• One card per referential shows each source's progress.
• The "Controls being analyzed" stream scrolls through the controls as they complete, with their referential, level and verdict, and — for warnings and non-compliances — the detailed finding, for example "7 service principal(s) hold a directory role: these identities bypass MFA and PIM, and their justification must be documented".

10.3 Verdicts

10.4 How the score is calculated

The compliance score is weighted by criticality, not computed as a plain ratio:

control weight :  L1 → 3     L2 → 1

points earned  :  compliant       → 100 % of the weight
                  warning         →  50 % of the weight
                  non-compliant   →   0

score = points earned / points available × 100

A plain "compliant controls / assessed controls" ratio would treat missing MFA on admin accounts the same as a minor OneDrive sharing tweak. The weighting corrects that: the score reflects risk, not headcount.

The same weighting is applied to the dashboard's per-referential breakdown, which is why a referential showing "15 / 58 compliant" can score 38 % rather than 26 %: controls do not all carry the same weight, and warnings count for half.

10.5 End of audit

When the run finishes, a banner summarizes the score, the verdict split and the duration. As an order of magnitude, 194 controls across six referentials complete in about 16 seconds with the default parallelism setting. The audit is saved to the company's history automatically; a link takes you straight to its detail.

11. Results, history and comparison

11.1 The results screen

Five headline figures give the immediate picture: controls assessed, compliance percentage, and counts of compliant, non-compliant and warning results. Each of the last three is clickable and filters the list below.

Three tools refine the display:

• A search box over control titles.
• A filter by referential.
• A filter by level (L1 / L2).

An "X / Y" counter always shows how many controls are displayed out of the total.

11.2 A control's detail

Clicking a row expands it to reveal:

• Result — the actual finding, with the values observed in the tenant.
• Description — what the control checks.
• Remediation — the fix path in the Microsoft portals.
• Frameworks — the control's compliance mappings.
• Learn more — the link to the Microsoft documentation.

11.3 The history

Each row shows the date and time, the number of controls assessed, the referentials covered as badges, the score, the compliant / non-compliant / warning split and the point difference against the previous audit (green for a rise, red for a fall, or "stable"). Full detail opens on click.

Filters at the top narrow the display to a period (30 days, 90 days, 12 months, all) and to a referential, with an "X shown of Y" counter. That filtering is purely visual: differences are still computed over the complete sequence of audits.

A CSV export of the history is available from the header: scores, differences, baseline applied, referentials covered, reference flag and auditor note.

11.4 Notes and reference audits

Two features make the history usable over time:

• The auditor note — a free-text field attached to each audit, editable from its detail. An italic preview appears on the row in the history. This is where to record context: "initial audit before remediation", "after Conditional Access rollout", "reduced scope, Exchange unavailable".
• Reference audits — an audit can be pinned: it then carries a REFERENCE badge and a star on its row. A pinned audit is excluded from retention purging and from the volume safeguard: it will never disappear automatically. Always pin the initial audit of an engagement, since it is the comparison point for every one that follows.

11.5 Comparing two audits

The Compare two audits button in the history opens a dedicated screen. You pick audit A (before) and audit B (after), and the application reports:

• The score before, the score after and the difference.
• The number of controls that became compliant (Compliant +) and left non-compliance (Non-compliant −).
• Regressed controls — those that were compliant and no longer are. Handle these first: a regression almost always signals an unmanaged configuration change.
• Improved controls — those fixed since the reference audit. This is the substance of the debrief: proof of the work done.
• Evolution per referential, source by source.

The comparison is exportable, which makes it the natural support for a steering committee or an end-of-remediation review.

11.6 Retention

History is kept for 36 months, beyond which the oldest audits are purged automatically — except those pinned as reference audits. A Clear history button also allows a manual purge, which is irreversible.

12. The dashboard

The dashboard gives the overall picture of the active company's posture. It draws on the most recent audit for each referential: re-auditing a single referential only refreshes that part, the rest keeping its last known value.

12.1 Overall compliance

A summary chart — whose type you can choose — shows the overall compliance percentage, computed with the weighting described in § 10.4. Alongside it, one card per referential gives its own percentage with a progress bar and a status dot.

12.2 Compliance by referential

A dedicated block breaks down, referential by referential, the weighted split of controls between compliant, warning and non-compliant, as stacked bars. Referentials are sorted from least to most compliant: the first in the list is where to put the effort. Each row restates the raw count ("15 / 58 compliant") next to the weighted percentage.

12.3 Trend

A trend chart traces the compliance percentage over time, either overall or referential by referential. This is the curve to show in a steering committee: it makes the effect of remediation visible, and equally, silent drift.

12.4 How to read the dashboard

• A low overall score is not a failure in itself: a first audit on a tenant that has never been hardened commonly lands between 40 % and 60 %. What matters is the trajectory.
• Look at L1 non-compliances before the percentage: ten failed L1 controls carry more real risk than thirty L2s.
• A referential at 100 % on very few controls usually signals a partly working connector rather than configuration excellence.
• A sudden drop in the score calls for a comparison (§ 11.5) before any conclusion: it comes from a change of scope more often than from a real regression.

13. Reports and exports

13.1 The principle

Exporting crosses two independent dimensions: a report type, which sets the editorial angle and the contents, and one or more file formats, which set the medium. The type chosen applies to every format exported from an audit's detail.

13.2 The four report types

13.3 The five formats

Formats are enabled independently in Settings › Export. HTML and PDF are on by default. Only enabled formats appear as export buttons in an audit's detail.

13.4 Header and cover

Three elements drive report layout:

• Exported reports carry the license holder's name (the application name) and the date in the header and footer (§ 4.2). That is your issuer identity.
• The contact (email or phone) accompanies that identity.
• The audited company's logo, set on its record, fills the cover page of the executive report.

13.5 Exporting

1. Open the audit from the history.
2. Check the report type selected in Settings › Export.
3. Click the button for the format you want, at the top of the results list.
4. Choose where to save.

13.6 Which report for which use

13.7 The other exports

• History — CSV export of a company's complete audit sequence: scores, differences, baselines, referentials, notes.
• Portfolio — CSV export of the company list with their posture (last audit, score, difference).
• Comparison — export of the delta between two audits.

14. Performance

14.1 Parallelism

The Settings › Performance screen sets how many controls are analyzed at once, from 1 to 16, with a default of 8. Raising it speeds the audit up but puts more load on the Microsoft APIs, with a risk of throttling.

14.2 The benchmark

The Run test button measures how long a simulated audit takes at various parallelism levels and names the optimum on this machine. On the run shown above: 0.99 s sequentially, 0.34 s at 8 threads (2.9× faster), and a slight degradation at 16 — past a certain point, contention costs more than it gains. Apply keeps the measured value.

14.3 Throttling

The network connectors self-limit to stay under the Microsoft APIs' throttling thresholds. An audit that slows down noticeably mid-run on a very large tenant is that regulation at work: it is normal and protective, and should not be worked around by raising parallelism, which would have the opposite effect.

15. Appendices

Appendix A — File layout

C:\Program Files\EntraGUARD\        program (replaced on every update)
C:\ProgramData\EntraGUARD\          data (never touched by a reinstall)
├── license.key
├── control-packs\
├── connector-packs\
└── clients\<slug>\
    ├── settings.json
    └── audit.db

HKCU\Software\EntraGUARD\ActiveClient

Appendix B — Troubleshooting

Appendix C — A typical engagement

Appendix D — Security and confidentiality

• No writes to the audited tenant: every permission requested is read-only.
• No data leaves the workstation: no middleman service, no telemetry, nothing sent back to the vendor. The only outbound connections are to the Microsoft APIs being queried.
• Offline license verification: no activation server is contacted.
• Secrets encrypted with DPAPI at machine scope: a configuration file copied elsewhere is unreadable (§ 6.10).
• No content is read: the application reads configuration settings and directory object metadata, never the contents of messages, files or conversations.
• The audit workstation is a sensitive asset: it concentrates read access to several clients' tenants. Disk encryption, a locked session and restricted physical access are prerequisites, not options.
• Reports contain detailed configuration data about a client tenant. Send them over a secure channel and retain them according to the retention policy agreed in the contract.

Appendix E — Glossary