Copilot Readiness Assessment: permissions and privacy
How the JFDI M365 Copilot Readiness Assessment handles permissions, authentication and customer data. A read-only assessment that runs and processes data locally, sends no tenant assessment data to JFDI during normal operation, supports a customer-owned service principal, and can be revoked at any time.
How the JFDI M365 Copilot Readiness Assessment handles permissions, authentication and customer data.
The assessment is a read-only desktop application that runs locally, processes assessment data on the machine that runs it, does not send tenant assessment data to JFDI Consulting during normal operation, supports both delegated and customer-owned service-principal authentication, and can be revoked at any time.
This page is written for Microsoft 365 administrators, security reviewers and governance teams who need to understand the access required before running the assessment against a live tenant.
The assessment connects to your Microsoft 365 tenant, analyses configuration and security posture, and generates actionable recommendations to help prepare for AI adoption across Microsoft 365, Entra ID, SharePoint, OneDrive, Teams, Exchange Online, Defender, Purview and Power Platform.
Summary
The assessment is a high-trust, read-only administrative assessment tool.
It requires broad tenant visibility because Microsoft 365 Copilot can surface information from across the data, permissions and governance controls that already exist in Microsoft 365. The assessment does not create, update or delete tenant resources. It processes assessment data locally and generates reports locally.
For production assessments, JFDI recommends using a customer-owned Microsoft Entra application registration and service principal so that the application, credentials, permissions and lifecycle remain under your organisation’s administrative control.
For formal security review, customers can request a security review pack before deployment. This can include the current permissions manifest, expected network endpoint list, file hashes, signing certificate details, sample reports, service principal setup scripts, manual setup guidance and written data-handling confirmation.
Access can be revoked after the assessment.
Plain-English risk position
This is not a low-permission end-user utility. It is a read-only administrative assessment tool that requires broad Microsoft 365 visibility to evaluate Copilot readiness properly.
For that reason, JFDI recommends treating deployment as a formal security-reviewed administrative activity: use a customer-owned service principal, review the permission manifest and endpoint list, run from a controlled administrator workstation, protect the generated reports, and revoke access when the assessment is complete.
The benefit of this model is that broad access is temporary, customer-controlled, locally processed and auditable through Microsoft administrative controls.
Recommended safe deployment model
For production tenants, JFDI recommends the following approach:
- use a customer-owned Microsoft Entra application registration and service principal
- review the permission manifest before granting consent
- review the expected endpoint list before execution
- run the assessment from a controlled administrator workstation
- grant the minimum permissions your organisation is comfortable approving initially
- accept reduced coverage where permissions, services or licences are unavailable
- monitor outbound traffic if required by your security process
- store generated reports in an approved secure location because they may contain sensitive tenant findings
- revoke or disable the assessment application after report generation if ongoing access is not required
Interactive authentication using JFDI’s Entra application is intended for evaluation, proof-of-concept work and limited assessments where your organisation accepts delegated-user execution.
For production use, the customer-owned service principal model gives your organisation the strongest control over consent, credentials, execution, monitoring and revocation.
Why a readiness assessment needs broad visibility
Microsoft 365 Copilot operates across the information, permissions and governance structures that already exist within your Microsoft 365 environment.
Many organisations discover issues such as:
A readiness assessment helps identify these issues before broad AI deployment, allowing organisations to improve governance, reduce risk and maximise the value of Copilot.
To do that accurately, the assessment needs tenant-wide read visibility across the workloads Copilot and related AI capabilities may draw on.
Security and privacy
Read-only assessment
The assessment gathers evidence, configuration data, permission information and governance signals only.
It does not create, modify or delete users, groups, sites, files, mailboxes, Teams, policies, Power Platform environments or tenant configuration.
Local processing
Assessment data is processed locally on the machine running the application.
Generated reports are stored locally. They are not uploaded to JFDI Consulting as part of normal operation.
Generated reports may contain sensitive tenant information, including configuration details, permission findings, exposure indicators, security observations and remediation priorities. They should be stored, shared and retained according to your organisation’s security classification and document-handling policies.
No tenant assessment data sent to JFDI
Tenant data, raw assessment evidence and generated reports are not transmitted to JFDI Consulting or any third party as part of normal operation.
The only expected tenant-data traffic during normal assessment execution is between the machine running the assessment and Microsoft 365 services required for authentication and assessment data collection.
Any JFDI-controlled endpoints used for licence validation, update checks, support diagnostics or similar functions are documented separately in the endpoint list and should be reviewed before deployment. These functions are separate from tenant assessment data collection. Specifically, licence activation transmits your Microsoft Entra Tenant ID to a JFDI-hosted licensing service to validate the licence; it sends the tenant identifier only, never assessment content.
If you choose to share reports, logs or exported evidence with JFDI for support, consultancy or troubleshooting, that is a separate customer-controlled action.
No training use
Customer tenant data and generated reports are not used to train AI models.
Runtime and token handling
The application is self-contained and does not require a separate .NET runtime installation.
The application runs only when launched by the customer. It does not install a background service.
Authentication tokens are held in memory only for the duration of the assessment session. They are not persisted to disk.
Where service principal authentication is used, the customer supplies the tenant ID, client ID and credential details through a local configuration file. The customer is responsible for protecting that file and removing it when it is no longer required.
Microsoft auditability
Authentication, consent and API access remain subject to Microsoft Entra, Microsoft 365 and workload audit logging according to the customer’s licensing, audit configuration and retention settings.
The assessment does not bypass Microsoft identity, consent, audit or administrative controls.
What the assessment does not do
The assessment does not:
Authentication options
Two authentication models are available. Both authenticate using Microsoft identity. They differ in the permission model they use and the assessment coverage they unlock.
Interactive authentication
Interactive authentication uses JFDI’s Microsoft Entra application and acts as the signed-in user.
It is suitable for evaluations, proof-of-concept work and initial assessments where delegated permissions are sufficient.
Characteristics:
Interactive authentication is convenient, but it may provide limited coverage for areas where Microsoft requires application permissions or service-specific administrative access.
JFDI does not recommend relying on interactive authentication for comprehensive production tenant assessments unless your organisation has reviewed and approved that model.
Service principal authentication
Service principal authentication uses an application registration created in your own Microsoft Entra tenant, under your own administrative control.
This is the recommended model for production assessments and larger environments.
Characteristics:
For production tenant assessments, JFDI recommends the customer-owned service principal model. It avoids reliance on a persistent third-party enterprise application and gives your organisation full control over permissions, credentials and lifecycle management.
Customers can inspect the supplied setup scripts before running them, run them through their normal change-control process, or perform the equivalent configuration manually.
Customer-owned service principal setup
The service principal setup scripts create or update a single-tenant app registration in the customer’s own Microsoft Entra tenant.
When creating a new service principal, the app registration is named:
JFDI M365 Copilot Readiness Assessment (Service Principal)
The scripts can:
The scripts use application permissions, not delegated permissions, for the service principal model.
Some permissions depend on licensing, service activation or tenant availability. Where a Microsoft service principal or permission is not available, the script skips it and the assessment runs with reduced coverage.
What the setup scripts do not do
The setup scripts do not create, modify or delete tenant business data.
The setup scripts do not assign Compliance Administrator, Exchange Online RBAC, Purview role-group membership or other high-privilege administrative role assignments automatically.
For broad Purview and Security & Compliance PowerShell coverage, customers must separately approve and assign an appropriate Microsoft Entra role or equivalent Exchange Online / Purview RBAC role to the application service principal.
This separation is intentional. The API permission Exchange.ManageAsApp enables app-only Exchange Online and Security & Compliance PowerShell connectivity, but effective cmdlet access is controlled by the role or RBAC assignment granted by the customer.
The setup scripts do not bypass Microsoft identity, consent, audit or administrative controls.
Credentials created by the setup scripts
By default, the setup scripts create a client secret for the customer-owned app registration. By default, the generated client secret has a two-year expiry.
The client secret is displayed only once during setup. Customers should store it securely and protect any local configuration file containing it.
For service principal authentication, the assessment uses a local .env file placed beside the assessment executable. This file contains:
TENANT_ID
CLIENT_ID
CLIENT_SECRET
Where certificate-based Purview PowerShell support is used, the .env file also includes:
CERTIFICATE_THUMBPRINT
Customers should protect the .env file with appropriate filesystem permissions and should remove it when the assessment is complete if ongoing access is not required.
For organisations that do not want a long-lived client secret, JFDI recommends creating a shorter-lived secret, using certificate-based authentication where appropriate, or deleting the secret immediately after the assessment.
Optional certificate for Purview coverage
For broad Purview assessment coverage, certificate-based authentication may be required for app-only Exchange Online and Security & Compliance PowerShell.
The setup scripts can optionally generate a self-signed certificate for this purpose.
Where certificate authentication is used, customers should protect the private key and any PFX file. These files must not be committed to source control, shared unnecessarily or stored in a public location.
Access revocation
Access can be revoked at any time.
For interactive authentication, revoke consent by removing the enterprise application associated with the assessment from Microsoft Entra ID.
For service principal authentication, revoke access by deleting or disabling the customer-owned application registration, removing its credentials, and removing any Exchange Online, Purview, Power Platform or service-specific role assignments granted for the assessment.
Where the assessment is run as a one-off exercise, JFDI recommends revoking or disabling the assessment application after the reports have been generated and validated.
Customers using Azure CLI can delete the app registration with:
az ad app delete --id <CLIENT_ID>
Customers should also remove any local .env file, exported certificate files, PFX files or private keys that are no longer required.
Graceful degradation
The assessment is designed to degrade gracefully.
Where a workload, licence, service or permission is unavailable, the assessment continues and reports on the areas it can access.
Examples include:
Where coverage is limited, the assessment highlights the affected areas and continues processing the remaining workloads. This allows organisations to begin with a lower-permission assessment and expand coverage later if required.
Findings based on limited visibility are identified so administrators can distinguish between complete assessment coverage and partial assessment coverage.
A reduced-permission assessment can be useful for an initial review. A comprehensive production readiness assessment requires the relevant Defender, Purview, Power Platform and Microsoft 365 permissions and role assignments to be approved.
Permissions
The assessment requires tenant-wide read access across Microsoft 365 workloads in order to evaluate readiness, security posture, governance controls and AI exposure risks.
Permissions cover areas including:
The assessment requests read-oriented permissions because it needs to inspect configuration, access, sharing, governance and security posture. It does not request permissions in order to modify tenant content or configuration.
Some Microsoft permissions are broad by design. Security reviewers should treat them as high-trust administrative read permissions, even though the assessment itself is read-only.
A detailed permissions reference is included with the product documentation. Security reviewers can request the current permissions manifest, application details and service principal setup materials before deployment.
Permission categories
Depending on authentication mode, licensing and selected assessment coverage, permissions may include:
| Area | Purpose |
|---|---|
| Microsoft Graph | Identity, users, groups, applications, consent, audit logs, reports, policies, Teams, SharePoint, OneDrive, meetings, information protection and related Microsoft 365 configuration |
| Microsoft Threat Protection | Defender XDR incidents and advanced hunting where available |
| Microsoft Defender for Endpoint | Device inventory, exposure score, vulnerabilities, security recommendations and software inventory where licensed |
| Office 365 Management APIs | Activity feed, audit-related data and service health |
| Office 365 Exchange Online | App-only Exchange Online and Security & Compliance PowerShell connectivity for broad Purview report coverage |
| Power Platform | Environment, app, flow, connection and DLP policy assessment where the service principal is registered as a Power Platform Management App |
In service principal mode, these are application permissions and should be reviewed as tenant-wide administrative read access.
Understanding broad read permissions
Some of the permissions used by the assessment, especially those relating to SharePoint and OneDrive, can appear broad during consent review.
This is expected. Copilot readiness cannot be assessed only from licence assignment or high-level tenant settings. The areas that create the greatest Copilot readiness and information-governance risk are often found in existing content locations, sharing arrangements, group memberships, site permissions, external access settings and governance controls.
Security review should consider three separate points:
- what the Microsoft permission technically allows
- what the JFDI assessment is designed to do
- how the customer controls, validates and revokes access
The permission may technically allow broad read access. The assessment uses that access to evaluate readiness, exposure, governance and risk. The customer controls consent, execution, report storage and revocation.
Because the application is closed-source commercial software, customers should review the available assurance artefacts, validate the executable, inspect the requested permissions, monitor execution where required, and apply their own contractual and security controls before using it in production.
Why does the assessment require Sites.Read.All and Files.Read.All?
These permissions often attract the most attention during security reviews because they provide broad visibility into SharePoint Online and OneDrive.
They are requested because Microsoft 365 Copilot operates across SharePoint and OneDrive content and permissions. Assessing Copilot readiness requires understanding:
Without these permissions, the assessment would have limited visibility into the areas that most commonly create Copilot adoption and information governance risks.
In application-permission mode, Microsoft treats permissions such as Files.Read.All and Sites.Read.All as broad tenant-level read permissions. Security teams should review and approve them as high-trust administrative permissions.
The JFDI assessment uses these permissions to assess configuration, permissions, sharing posture, governance controls and AI readiness. It does not provide users with a document search interface, bulk document export function or content harvesting workflow.
Assessment data is processed locally and reports are generated on the machine running the application. Tenant assessment data is not transmitted to JFDI as part of normal operation.
For organisations with strict security requirements, the service principal deployment option allows the assessment to run using an application registration that exists entirely within your own Microsoft Entra tenant and administrative control.
Exchange.ManageAsApp and Exchange Online access
Exchange.ManageAsApp may be required for app-only Exchange Online and Security & Compliance PowerShell connectivity.
The assessment uses this capability to gather Exchange, Purview and compliance-related information where available. Effective access is controlled by the Microsoft Entra permissions and Exchange role assignments granted to the application.
The assessment does not use this access to create, update or delete mailboxes, messages, compliance policies or tenant configuration.
Where your organisation does not grant the required Exchange Online or Purview access, the assessment continues with reduced coverage and identifies the affected areas in the output.
For broad Purview coverage, the assessment may require:
The setup scripts do not assign the high-privilege role automatically. Customers approve and assign that access separately.
Power Platform access
For broad Power Platform coverage in service principal mode, the service principal must be registered as a Power Platform Management App.
This registration grants admin-level read access for Power Platform assessment purposes, including visibility of:
The setup scripts attempt this registration where the required PowerShell module and administrator sign-in are available. In some environments, this step must be completed manually by a Power Platform administrator.
If the service principal is not registered as a Power Platform Management App, the assessment can still run, but Power Platform findings may be incomplete or unavailable.
Registration can take up to 30 minutes to propagate.
Defender XDR activation
Broad Defender reporting depends on licensing, service activation and API availability.
If Microsoft Defender XDR is licensed but has not previously been activated in the tenant, an administrator may need to visit the Microsoft Defender portal and complete the initial activation process before telemetry can be retrieved.
Provisioning can take time. Until Defender XDR and related APIs are available, the assessment continues with reduced Defender coverage and identifies the affected areas.
Tenants without the required Defender licensing can still receive licence-based recommendations where available.
Assessment coverage
Interactive authentication is sufficient for evaluations and initial assessments.
For comprehensive readiness reporting, service principal authentication is recommended because some Defender, Purview and Power Platform data is only available through application permissions or service-specific administrative access.
| Area | Interactive authentication | Service principal |
|---|---|---|
| Microsoft 365 | Broad | Broad |
| Entra ID | Broad | Broad |
| SharePoint and OneDrive | Broad | Broad |
| Teams | Broad | Broad |
| Defender | Limited | Broad |
| Purview | Limited | Broad |
| Power Platform | Limited | Broad |
| Copilot Studio | Broad | Broad |
“Broad” means the assessment can collect the principal evidence required for that area, subject to Microsoft licensing, tenant configuration, administrator consent, API availability and role assignments.
Coverage depends on licensing, enabled workloads, tenant configuration, Microsoft API availability and the permissions granted.
Same broad evidence base, more assessment output
The JFDI assessment is designed to work from the same kind of broad Microsoft 365 evidence base required by Microsoft’s own Copilot readiness tooling: tenant configuration, identity, SharePoint, OneDrive, Teams, Exchange, Defender, Purview, Power Platform and related governance signals.
The JFDI assessment then adds consultant-grade analysis, scoring, prioritisation and deliverables, including readiness insights and reports that go beyond basic technical checks.
Depending on licensing and granted permissions, outputs may include:
The purpose is not just to identify whether Copilot can be enabled. It is to help organisations understand what should be fixed before broad deployment.
System requirements
Supported platforms
The assessment supports:
Platform notes
Windows is recommended for maximum coverage.
Linux and macOS can run the assessment, but broad Purview PowerShell coverage requires native Windows because the ExchangeOnlineManagement module uses the Windows certificate store for certificate-based app-only authentication.
On macOS, the operating system may block the application if it is not signed through the Apple Developer Programme. Customers should validate the application package, publisher, checksum and source before choosing whether to allow it through Gatekeeper.
Additional requirements
The machine running the assessment requires:
For broad Purview coverage, the machine running the assessment may also require:
For service principal setup, administrators may also require:
Download, validation and SmartScreen
The application is delivered as a standalone executable package.
Because this is a specialist enterprise administration tool rather than a mass-market consumer application, Windows SmartScreen may display a warning when running it for the first time.
Do not bypass SmartScreen solely because this page says the tool is legitimate. Validate the download first and follow your organisation’s software approval process.
Before extracting or running the application:
- download the package only from an official JFDI source
- confirm that the download URL was supplied through JFDI’s official website or by an authorised JFDI contact
- check the version number and release date
- validate the file hash
- validate the publisher signature if the package or executable is signed
- scan the package using your organisation’s standard endpoint protection or malware analysis process
- right-click the downloaded file and select Properties
- if an Unblock option is present and your organisation permits this after validation, enable it
- select Apply and OK
- extract the archive and run the application
If SmartScreen still appears, select More info only after completing your validation checks. Verify the application name, publisher and source before choosing whether to run the application.
Administrators should follow their own software validation, endpoint protection and change-control procedures before running any downloaded executable.
Expected network traffic
During normal assessment execution, the application connects to Microsoft identity and Microsoft 365 service endpoints required for authentication and assessment data collection.
Depending on the selected assessment scope, these may include Microsoft services such as:
Common Microsoft endpoints may include:
Additional Microsoft 365, Defender, Exchange Online, Purview, Office 365 Management, Power Platform or Power Automate endpoints may be used depending on tenant configuration, licensing and selected assessment coverage.
The assessment does not upload tenant assessment data, raw evidence or generated reports to JFDI as part of normal operation.
Any JFDI-controlled endpoints used for licence validation, update checks, support diagnostics or similar functions are documented separately from tenant assessment data collection.
The current endpoint list is provided as part of the security review pack. This list identifies expected Microsoft endpoints and any JFDI-controlled endpoints used by the application, so that administrators can complete allow-listing, proxy, firewall, EDR or network monitoring reviews before execution.
If your organisation requires network validation, run the assessment from a controlled administrator workstation and monitor outbound traffic during execution.
Included documentation
Each download includes:
Frequently asked questions
Questions about permissions or deployment?
If you would like to review permissions, authentication requirements, deployment options or the security review pack before purchase, please get in touch. JFDI can help determine the most appropriate authentication model for your environment and support your internal security review before the assessment is run.