Glossaire

Termes du parc Microsoft, expliqués.

Définitions claires pour les abréviations et termes produits qui apparaissent sur les pages EfficientEther, les revues de parc Microsoft et les conversations opérationnelles.

Parcourir les ressourcesDemander à l'équipe
127 définitions10 catégoriesLangue claire descriptions
DEFG

D

DefenderIdentity and security

Microsoft Defender XDR

Microsoft Defender XDR is the unifying layer that sits above Microsoft's individual security products, Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps, correlating their separate alert streams into a single incident rather than leaving analysts to manually piece together fragments from four different consoles. The underlying idea behind extended detection and response is that a real attack rarely stays confined to one layer: a phishing email that delivers a malicious attachment, which then runs on an endpoint, which then uses stolen credentials to move laterally through the identity layer, generates alerts in three separate products, and without correlation those alerts look like three unrelated low-priority events rather than one coherent attack chain. Defender XDR's incident graph automatically links related alerts, affected users, devices, and mailboxes into a single 'attack story' with a unified severity and priority, and its automated investigation and response capability can, depending on configuration, automatically remediate common patterns such as isolating a compromised device or removing a malicious email from every inbox it reached, without waiting for a human to correlate the same evidence manually. All of this is accessed through the unified Microsoft Defender portal at security.microsoft.com, which has progressively absorbed what used to be separate admin experiences for each Defender product, and which also surfaces Microsoft Secure Score, threat analytics, and hunting queries written in the same Kusto-based query language used across the suite. For organisations running a security operations function, Defender XDR data flows into Microsoft Sentinel for longer-term retention, cross-product correlation with non-Microsoft signals, and SIEM-style investigation, so the two products are generally deployed together rather than as alternatives: Defender XDR handles fast, product-native detection and response, while Sentinel adds broader analytics and case management. Licensing is the detail that most often trips organisations up, since full XDR capability, rather than the baseline protection bundled into standard Microsoft 365 plans, generally requires Microsoft 365 E5 or the equivalent standalone add-ons for each underlying Defender product, meaning an organisation can appear to have 'Defender' enabled while actually running well below the licence tier needed for automated investigation, advanced hunting, or the full incident correlation the platform is designed around, and the resulting alert fatigue from unlinked, per-product alerts is often the first practical symptom of that gap.

Defender matters because identity, access, endpoint, and data controls shape how Microsoft environments are protected. Readers should understand the term and then be able to move into security assessment, conformity, or remediation guidance.

Security and conformity solutionExplore EtherInsights
Defender for Cloud AppsIdentity and security

Microsoft Defender for Cloud Apps

Microsoft Defender for Cloud Apps is Microsoft's cloud access security broker, sitting between users and the cloud applications they use to give an organisation visibility and control over sanctioned and unsanctioned cloud application use that traditional endpoint or network security tools were never designed to see. Its shadow IT discovery capability analyses traffic logs from firewalls and secure web gateways, or from the Defender for Endpoint sensor already deployed on managed devices, to build an inventory of every cloud application actually being used across the organisation, cross-referencing each one against a continuously maintained Cloud App Catalog of thousands of applications scored against dozens of risk factors, data handling practices, compliance certifications, breach history, so that a security team discovers not just that fifty different file-sharing services are in active use, which is itself often a surprise, but which of those specifically pose a meaningful risk and warrant action. For applications the organisation formally sanctions, principally the Microsoft 365 suite itself but extending to popular third-party SaaS like Salesforce, Box, or Workday, API-based connectors give Defender for Cloud Apps direct, out-of-band visibility into data at rest, scanning files for malware and sensitive content, applying DLP policies, and flagging anomalous sharing without sitting in the live traffic path at all. Conditional Access App Control takes a different approach for real-time enforcement, reverse-proxying application sessions so that specific actions, such as downloading a file, printing, or copying data to the clipboard, can be blocked or restricted based on the user's device compliance state and risk level, in the moment, rather than only after the fact, which is what lets an organisation permit access to a sanctioned SaaS application from an unmanaged personal device while still preventing sensitive data from actually being downloaded onto it. Activity policies and built-in anomaly detection round out the picture by flagging behavioural patterns that suggest compromise or misuse, impossible travel, where the same account authenticates from two geographically implausible locations within a short window, mass download or mass deletion events consistent with data exfiltration or ransomware staging, and unusual administrative activity, generating alerts that feed into the broader Defender XDR incident correlation alongside signals from endpoint, email, and identity. Defender for Cloud Apps is bundled into Microsoft 365 E5 and available as a standalone add-on for lower tiers, and its practical value scales directly with how much genuinely unsanctioned cloud application use an organisation actually has, meaning the discovery phase alone, run before any policy is configured, is often the point at which security and finance stakeholders first see, in concrete terms, how much shadow IT and associated duplicate spend has accumulated outside official procurement.

Defender for Cloud Apps matters because identity, access, endpoint, and data controls shape how Microsoft environments are protected. Readers should understand the term and then be able to move into security assessment, conformity, or remediation guidance.

Security and conformity solutionExplore EtherInsights
Defender for EndpointIdentity and security

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint is Microsoft's endpoint protection platform and EDR product, combining preventative antivirus and attack surface reduction with continuous behavioural monitoring and investigation capability under a single lightweight sensor built into modern Windows and available as an installable agent for macOS, Linux, iOS, and Android, giving organisations one console covering their genuinely mixed-OS device estate rather than a separate tool per platform. It is licensed in two meaningfully different tiers: Plan 1 covers next-generation antivirus, attack surface reduction rules that block specific behavioural patterns commonly abused for exploitation, such as Office applications spawning child processes, and basic manual response actions, while Plan 2 adds the full EDR capability the product is best known for, behavioural sensors that reconstruct an attack timeline across process, file, network, and registry activity, automated investigation and remediation that can act on common patterns without waiting for analyst intervention, threat and vulnerability management that continuously inventories software and known CVEs across the device estate, and live response, a direct remote investigation and remediation session on an affected device. Device onboarding is where deployments most often develop silent coverage gaps: devices enrolled through Intune, Group Policy, a manual onboarding script, or a third-party RMM integration get the sensor and appear in the device inventory, but any device missed by whichever onboarding mechanism an organisation relies on sits completely outside visibility, generates no alert to flag its own absence, and can go unnoticed for months, which is precisely the kind of gap that gets discovered only during an actual incident when a compromised device turns out never to have been reporting in the first place. Tamper protection locks core security settings against being disabled locally, including by a user with local administrative rights, which matters directly against ransomware and other malware families that routinely attempt to disable endpoint defences as one of their first actions after gaining a foothold. Defender for Endpoint integrates closely with device compliance policies in Intune, so a device's real-time risk level as assessed by Defender for Endpoint can feed directly into Conditional Access decisions, meaning a device that develops active malware detections can be automatically marked non-compliant and lose access to corporate resources without requiring a manual response step, and it forms the endpoint pillar of Defender XDR, contributing telemetry and alerts that get automatically correlated with identity, email, and cloud app signals into unified incidents rather than sitting in an isolated endpoint-only view.

Defender for Endpoint matters because identity, access, endpoint, and data controls shape how Microsoft environments are protected. Readers should understand the term and then be able to move into security assessment, conformity, or remediation guidance.

Intune reporting solutionExplore EtherInsightsSecurity and conformity solution
Defender for Office 365Identity and security

Microsoft Defender for Office 365

Microsoft Defender for Office 365 is the advanced email and collaboration security layer that sits above the baseline anti-spam and anti-malware protection every Microsoft 365 mailbox already receives through Exchange Online Protection, adding the behavioural and detonation-based defences needed against modern phishing, business email compromise, and targeted malware delivery that signature-based filtering alone reliably misses. Safe Links rewrites URLs in email and Office documents so that when a link is actually clicked, it is checked against current threat intelligence at time of click rather than only at time of delivery, which matters because a link can be entirely benign when an email first arrives and get weaponised hours or days later, a pattern attackers deliberately exploit knowing static, delivery-time-only scanning will miss it. Safe Attachments extends the same time-of-use principle to file attachments by detonating them in an isolated sandbox environment before delivery, observing their actual runtime behaviour rather than relying solely on static signature matching, which catches malware built specifically to evade conventional antivirus detection. Anti-phishing policies and impersonation protection address business email compromise directly, a threat category that often carries no malicious link or attachment at all and so evades traditional malware-focused defences entirely, by analysing sender authentication signals, domain similarity to known trusted senders, and mailbox intelligence built from an organisation's own communication patterns to flag messages impersonating executives, known contacts, or the organisation's own domain. Threat Explorer and the related campaign views give security teams a queryable interface across all delivered, blocked, and quarantined mail, letting them search for a specific indicator across the entire tenant and see it as part of a wider campaign rather than an isolated message, while Zero-hour Auto Purge retroactively removes messages from inboxes after delivery once they are subsequently identified as malicious, closing the gap for threats that were missed at the moment of delivery but caught shortly afterward through updated threat intelligence. Like Defender for Endpoint, Defender for Office 365 is licensed in two tiers, Plan 1 covering the core protective features, Safe Links, Safe Attachments, and anti-phishing, and Plan 2 adding the investigative and automated response layer, Threat Explorer, automated investigation and response, and attack simulation training for running realistic phishing campaigns against an organisation's own users to measure and improve their real-world susceptibility. Because Exchange Online Protection is included in every Microsoft 365 plan by default, organisations sometimes assume their email is comprehensively protected when in fact they are running only the baseline layer, discovering the gap only after a phishing or business email compromise incident that Defender for Office 365's additional detection would very plausibly have caught.

Defender for Office 365 matters because identity, access, endpoint, and data controls shape how Microsoft environments are protected. Readers should understand the term and then be able to move into security assessment, conformity, or remediation guidance.

Security and conformity solutionExplore EtherInsights
DependencyApplication modernisation

Application dependency

An application dependency is a shared component, most commonly a runtime library or framework, that an application relies on to run correctly but does not include within its own package, and in an MSIX context dependencies are declared explicitly in the package manifest rather than assumed to already be present on the target machine the way a traditional installer often does. The most frequently encountered dependencies in a Windows packaging estate are framework packages such as the Visual C++ Runtime (VCLibs), the .NET runtime, and the Windows App SDK, each published as its own MSIX framework package that multiple applications can share rather than each application bundling its own private copy, which keeps individual application packages smaller and ensures every dependent application benefits when the shared framework receives a security update. Getting dependency declarations right is one of the more common sources of packaging failures that only surface at install or launch time rather than at build time: a manifest that declares a dependency on a framework version the target device does not have installed will fail to install, a dependency declared too loosely can pull in an untested framework version on a device with a newer one already present, and a dependency omitted entirely produces an application that installs successfully but crashes on launch because a required runtime component is missing, which is why dependency version ranges need deliberate testing rather than being copied unexamined from a template. This is a genuinely different failure mode from the dependency problems traditional installers created, commonly summarised as DLL hell, where multiple applications competing for the same shared, unversioned system location could silently overwrite one another's required library version; MSIX's framework package model keeps multiple versions of a shared dependency installed side by side and lets each application's manifest pin the version range it was actually tested against, which removes the silent-overwrite failure mode but replaces it with the discipline of keeping manifest dependency declarations accurate and current as applications and the shared frameworks they rely on are both updated over time. At estate scale, dependency management also becomes a governance question: tracking which framework versions are deployed across a device fleet, which applications depend on frameworks approaching end of support, and coordinating framework updates so that a security-driven bump to a shared runtime does not break an application whose manifest pinned an older, narrower dependency range than it should have.

Dependency matters during Windows 11, Intune, Azure Virtual Desktop, and Cloud PC programmes because application blockers can delay the whole rollout. The practical question is whether the term helps capture, package, sign, deploy, or troubleshoot an app with less rework.

Agentic app packaging solutionMSIX packaging solutionExplore EtherApps Forge
DLPIdentity and security

Data Loss Prevention

Data Loss Prevention, delivered in Microsoft's ecosystem primarily through Microsoft Purview, is a policy framework for detecting sensitive content, such as credit card numbers, national insurance numbers, health records, or custom pattern-matched data, and controlling what happens when that content is about to leave a managed boundary, whether that boundary is an email being sent externally, a file being shared from SharePoint or OneDrive, a message posted in Teams, or a document being copied to USB media or printed from a managed endpoint. Detection relies on sensitive information types, which are pattern- and keyword-based definitions Microsoft maintains and organisations can extend, alongside trainable classifiers that use machine learning to recognise content types like resumes or source code that do not reduce cleanly to a regular expression, and detection can also key off sensitivity labels applied through Microsoft Purview Information Protection, so a document already labelled 'Confidential' can trigger stricter DLP handling than an unlabelled one regardless of its literal content. Policy actions sit on a spectrum from silent audit-only logging, useful for understanding what a policy would actually catch before it starts blocking anyone, through user-facing policy tips that warn and allow an override with a business justification, to hard blocks that prevent the action outright, and getting this escalation path right matters enormously in practice, because a DLP rollout that jumps straight to blocking, before its detection accuracy has been tuned against real organisational data, tends to generate enough false positives and user friction that people either request bulk exceptions or find workarounds that defeat the policy's purpose entirely. Endpoint DLP extends the same policy engine onto Windows devices themselves through the Defender for Endpoint sensor, catching copy-to-USB, copy-to-network-share, and clipboard actions, and DLP for the Edge browser and for on-premises repositories through the Microsoft Purview scanner extend coverage further, meaning a mature deployment is rarely a single policy but a coordinated set spanning email, cloud storage, endpoint, and browser. The connection to insider risk is direct: Purview's Adaptive Protection can raise DLP enforcement automatically for a user already flagged as elevated risk by Insider Risk Management, tightening controls exactly where they are statistically most needed rather than applying uniform friction to every user regardless of behaviour. Full DLP capability generally requires Microsoft 365 E5 Compliance or the equivalent add-on, and organisations frequently discover, only once running compliant policies for a regulatory audit or a contractual data-handling requirement, that their licence tier only ever supported a much narrower subset of what DLP is capable of.

DLP matters because identity, access, endpoint, and data controls shape how Microsoft environments are protected. Readers should understand the term and then be able to move into security assessment, conformity, or remediation guidance.

Security and conformity solutionExplore EtherInsights
DPACompliance

Data Processing Agreement

A Data Processing Agreement (DPA) is a legally binding contract between a data controller, the organisation that determines the purposes and means of processing personal data, and a data processor, the organisation that processes that data on the controller's behalf, setting out the terms under which the processor is permitted to handle it. Under UK GDPR and the EU GDPR, a DPA is not optional or a nice-to-have: Article 28 specifically requires one wherever a controller engages a processor, and it must contain a defined set of mandatory terms, including the subject matter, duration, nature, and purpose of processing, the type of personal data and categories of data subjects involved, the processor's obligation to only process data on the controller's documented instructions, confidentiality commitments for anyone with access, appropriate technical and organisational security measures, terms governing the use of sub-processors (including a requirement to flow down equivalent obligations to them), assistance obligations to help the controller respond to data subject rights requests and breach notifications, and provisions for data deletion or return at the end of the engagement. For organisations operating in a Microsoft 365 and Azure environment, DPAs surface in two directions that are easy to conflate: Microsoft itself acts as a data processor for customer data in Microsoft 365 and Azure, with its processor obligations set out in the Microsoft Products and Services Data Protection Addendum referenced from the Microsoft Customer Agreement, while the customer organisation is simultaneously the controller for its own tenant data and often also a processor in its own right when it handles personal data on behalf of its own customers, meaning most MSPs and SaaS vendors serving other businesses need their own DPAs in place with their customers, not merely reliance on Microsoft's. A DPA is distinct from, though closely related to, an International Data Transfer Agreement or Standard Contractual Clauses, which are the separate mechanism required when personal data is transferred outside the UK or EEA to a jurisdiction not covered by an adequacy decision, and organisations sometimes mistakenly assume a signed DPA alone covers cross-border transfer compliance when Microsoft's own data residency and transfer mechanisms need to be checked separately for the specific Microsoft 365 or Azure regions and services in scope. In practice, DPA review is a standard item in vendor and supplier due diligence, and gaps most commonly surface around sub-processor transparency (whether the processor discloses and allows objection to new sub-processors), breach notification timelines that are tight enough to meet the controller's own 72-hour regulatory reporting obligation, and whether the DPA's security measures actually reflect what the processor does in practice rather than generic boilerplate language.

DPA matters because customers, resellers, and procurement teams need evidence that controls are defined, operated, and reviewable. A useful glossary definition should help a reader connect the term to audit preparation, policy work, or repeatable assurance activity.

Certifications and securityIT operations and compliance solution
DPIACompliance

Data Protection Impact Assessment

A Data Protection Impact Assessment is a structured privacy risk assessment used to identify, understand, and reduce data protection risks before launching a new processing activity or materially changing an existing one, rather than discovering those risks only after a system handling personal data is already live and any problems it introduces have already affected real individuals. Under UK GDPR and EU GDPR, a DPIA is not merely good practice but a specific legal requirement whenever processing is likely to result in a high risk to individuals' rights and freedoms, and both frameworks give concrete examples of processing that typically triggers this threshold, including systematic and extensive automated decision-making that produces legal or similarly significant effects on individuals, large-scale processing of special category data such as health or biometric information, and systematic large-scale monitoring of a publicly accessible area. A properly conducted DPIA covers several distinct elements rather than a single risk rating: a description of the processing itself, including its purpose and scope; an assessment of necessity and proportionality, asking honestly whether the processing genuinely requires the volume and sensitivity of personal data proposed, or whether a less data-intensive approach would achieve the same legitimate goal; identification of specific risks to individuals arising from the processing, such as unauthorised access, inaccurate automated inference, or excessive retention; and the concrete measures put in place to mitigate each identified risk before the processing goes ahead, not merely acknowledged as a residual concern. This assessment discipline has become directly relevant to AI and Copilot deployments specifically, because AI systems that process personal data at scale, particularly those making or materially influencing decisions about individuals, frequently meet the high-risk threshold that legally requires a DPIA, and Copilot readiness work in an organisation with meaningful personal data exposure should generally include, or at minimum explicitly consider, a DPIA covering how the AI system accesses, retains, and potentially surfaces personal data, rather than treating data-protection review as separate from and unrelated to technical and licensing readiness.

DPIA matters because customers, resellers, and procurement teams need evidence that controls are defined, operated, and reviewable. A useful glossary definition should help a reader connect the term to audit preparation, policy work, or repeatable assurance activity.

Certifications and securityIT operations and compliance solution

E

eDiscoveryCompliance

Microsoft Purview eDiscovery

Microsoft Purview eDiscovery is the set of tools within Microsoft Purview for identifying, holding, searching, and exporting content across Microsoft 365 workloads, including Exchange Online mailboxes, SharePoint and OneDrive sites, Teams chats and channel messages, and Viva Engage, in response to litigation, regulatory investigations, internal HR or compliance investigations, or subject access requests, structured across three tiers of increasing capability. eDiscovery (Standard), included broadly across Microsoft 365 plans, provides core case management, content search, and legal hold functionality sufficient for straightforward searches and preservation. eDiscovery (Premium), available with E5 or as an add-on, adds custodian management, legal hold notifications and tracking, review sets with deduplication and near-duplicate detection, communication threading that reconstructs email and chat conversations, and analytics such as email threading and predictive coding-style relevance review, which matter directly in any matter involving more than a handful of custodians since manually reviewing unstructured search results at scale is not realistic. A more recent Premium capability extends the same case and review-set workflow to Microsoft Copilot interaction data, reflecting that Copilot prompts and responses over an organisation's own content are themselves discoverable content requiring the same hold and review treatment as email or chat. The core preservation mechanism is the legal hold, which suspends normal retention and deletion for in-scope content the moment it is applied, meaning it must be scoped and applied before, not after, content the organisation is obligated to preserve is deleted or ages out under an existing retention policy, and a hold applied late is a common and serious operational failure since Purview cannot recover content already permanently purged. Search results and legal holds also interact directly with retention labels and policies configured elsewhere in Purview: a hold placed through eDiscovery Premium generally overrides a shorter retention or deletion policy on the same content for its duration, but organisations still need to understand how their configured retention and disposition rules behave in combination with an active hold rather than assuming the hold alone guarantees nothing has already been lost. For MSPs and IT teams, the most common practical mistakes are underestimating scope, missing custodians whose content lives in shared mailboxes, Teams private channels, or third-party-connected data sources rather than only their primary mailbox, and treating a keyword search as equivalent to a defensible legal hold when the two serve genuinely different purposes: search finds content, while a hold is what actually prevents it being lost, and a matter that later goes to litigation can turn on whether the hold was applied promptly, correctly scoped, and properly documented.

eDiscovery matters because customers, resellers, and procurement teams need evidence that controls are defined, operated, and reviewable. A useful glossary definition should help a reader connect the term to audit preparation, policy work, or repeatable assurance activity.

Copilot readiness solutionExplore EtherAssistCertifications and security
EDRIdentity and security

Endpoint Detection and Response

Endpoint Detection and Response describes a category of security tooling that continuously monitors what actually happens on a device, process creation, file writes, registry changes, network connections, memory behaviour, rather than relying solely on signature matching against a database of known-bad files, which is the fundamental limitation traditional antivirus was built around and modern malware routinely evades through polymorphism, fileless techniques, and living-off-the-land abuse of legitimate system tools like PowerShell. Microsoft's EDR implementation, Defender for Endpoint, ingests this behavioural telemetry into a cloud-based analytics engine that can recognise attack patterns across the sequence of events rather than any single event in isolation, surfacing alerts with a reconstructed timeline of what a threat actor actually did on the device, and it gives responders live response, a remote shell-like capability to investigate and remediate an active incident, run scripts, or collect forensic evidence directly on an affected endpoint without needing separate remote-access tooling. Attack surface reduction rules work alongside detection as a preventative layer, blocking specific behavioural patterns commonly abused in exploitation, such as Office applications spawning child processes or scripts running from email attachments, before they can execute at all, and EDR in block mode lets Defender for Endpoint's behavioural blocking take effect even on devices where a third-party antivirus product remains the primary, real-time protection engine, catching what that other product's own detections miss. Threat and vulnerability management is the piece that connects detection back to prevention at scale, continuously inventorying installed software and known CVEs across the managed device estate and prioritising remediation by actual exploitability and business context rather than raw CVSS score alone. The distinction worth being precise about is that EDR is reactive and investigative by nature, built around the assumption that some things will get past preventative controls and need to be detected, understood, and contained quickly, whereas endpoint protection platform capabilities like real-time antivirus scanning are preventative; Defender for Endpoint bundles both under one sensor and one console, which is why it is licensed in tiers, Plan 1 covering attack surface reduction and manual response, Plan 2 adding the full EDR, automated investigation, and threat and vulnerability management capability that most organisations actually mean when they say EDR. Onboarding coverage gaps are the most common practical failure mode: devices that were never enrolled through Intune, group policy, or a manual onboarding script sit completely outside EDR visibility, and because that absence produces no alert of its own, an unmonitored device can go unnoticed for months until it becomes the entry point in an actual incident.

EDR matters because identity, access, endpoint, and data controls shape how Microsoft environments are protected. Readers should understand the term and then be able to move into security assessment, conformity, or remediation guidance.

Intune reporting solutionExplore EtherInsightsSecurity and conformity solution
EMSMicrosoft cloud

Enterprise Mobility + Security

Enterprise Mobility + Security, universally abbreviated EMS, is Microsoft's licensing bundle for identity and device security services, sold as a standalone add-on (EMS E3 and EMS E5) and included as a component within the Microsoft 365 E3 and E5 suites. It groups together services that are functionally independent but commercially and operationally treated as a set: Microsoft Entra ID P1 or P2 for identity and access management, Microsoft Intune for mobile device and application management, Microsoft Defender for Identity for on-premises Active Directory threat detection, Microsoft Purview Information Protection for data classification and rights management, and Microsoft Defender for Cloud Apps at the E5 tier for cloud access security broker functionality. The distinction between EMS E3 and E5 matters considerably for licence planning: E3 covers baseline identity and device management, including Conditional Access, self-service password reset, and standard Intune device management, while E5 adds the higher-value security capabilities, notably Entra ID P2 with risk-based Conditional Access and Privileged Identity Management, and Defender for Identity, which are the features organisations most often discover they actually need only after a security incident or an audit finding forces the question. Because EMS is bundled inside Microsoft 365 E3 and E5, organisations already on those suites frequently do not need to buy EMS separately at all, and a genuinely common licence-optimisation finding in mixed estates is duplicate EMS standalone licences sitting alongside an M365 E3/E5 assignment that already grants the same entitlement, wasting spend on a redundant SKU the user does not need. The other frequent misstep runs the opposite direction: assigning EMS E5 broadly across a user base to get Entra ID P2's risk-based Conditional Access, when only privileged or high-risk accounts actually need that tier, while the bulk of standard users would be fully served by E3-level identity and device management. From an operational standpoint, EMS is less a single product a user logs into than a licensing wrapper that unlocks specific service tiers inside the Microsoft admin centres, so correctly reading which EMS SKU is assigned to which user, and which underlying service plans that activates, is a prerequisite for any serious Microsoft 365 licence audit or cost-reclaim exercise, since the entitlement is invisible in the interface a user actually works in day to day.

EMS matters because Microsoft 365, Azure, Windows 365, Teams, and related services are usually managed as one estate. The term connects to planning, cost, configuration, security, and day-two operational decisions across that estate.

Windows 365 and Cloud PC solutionExplore EtherInsights
Endpoint security policyEndpoint management

Microsoft Intune endpoint security policy

Endpoint security policies are a distinct, security-team-focused set of policy types within Intune, found under the Endpoint Security node of the admin console rather than alongside general configuration profiles, covering disk encryption (BitLocker and FileVault), firewall rules, antivirus and Microsoft Defender configuration, endpoint detection and response (EDR) onboarding to Microsoft Defender for Endpoint, attack surface reduction rules, and account protection settings such as local administrator password management through Windows LAPS. Functionally, most endpoint security policies configure the same underlying CSPs that a general configuration profile could also set, and the split exists primarily for organisational and role-based reasons: it lets a dedicated security team own and manage security-specific configuration, with its own assignment and reporting surface, separately from a broader device management team's Wi-Fi, VPN, and general restriction profiles, which matters in larger organisations where those two functions sit in genuinely different teams with different change control processes. This separation is also exactly where duplicate or conflicting settings creep in, since it's entirely possible for a general configuration profile and an endpoint security policy to both target the same CSP, for instance firewall state, with different values, producing the same kind of unresolved conflict that affects overlapping configuration profiles generally, and it's a common oversight for organisations to build out endpoint security policies without checking whether an existing configuration profile already sets the same underlying settings. Microsoft Defender for Endpoint integration is one of the more operationally significant pieces here: onboarding devices for EDR through an endpoint security policy is what actually connects Intune-managed devices into Defender's detection and response capability, and a device that's compliant and encrypted but never received its Defender onboarding policy is fully patched and locked down on paper while remaining invisible to the organisation's actual threat detection tooling, a gap that's easy to miss because it doesn't show up as a compliance failure the way a missing BitLocker or password policy would. Attack surface reduction rules and account protection policies, including Windows LAPS for rotating local administrator passwords automatically, are newer additions to this policy family and are commonly under-deployed relative to the more established encryption and antivirus policies, partly because they require a slightly different mental model, reducing the practical impact of a compromise rather than checking a static compliance state, and partly because retrofitting them into an estate with existing local admin practices or software that assumes predictable local admin credentials takes more careful rollout planning than most other Intune policy types. Because these policies sit at the sharpest end of an organisation's actual security posture rather than just its reported compliance percentage, gaps here are disproportionately consequential relative to their visibility, and reviewing endpoint security policy coverage against the full device estate, not just against what's assigned versus what compliance policy reports as passing, is a worthwhile distinct exercise from general Intune policy auditing.

Endpoint security policy matters for endpoint teams because device, app, compliance, update, and troubleshooting signals often sit across several Microsoft admin areas. Linking these terms back to Intune and device-reporting routes helps readers move from definition to action.

Intune reporting solutionExplore EtherInsights
EntraMicrosoft cloud

Microsoft Entra

Microsoft Entra is Microsoft's product family name for identity and network access services, introduced in 2023 as an umbrella brand that consolidated what had previously been marketed under separate names, most visibly renaming Azure Active Directory to Microsoft Entra ID while keeping its underlying service, tenant structure, and object model unchanged. The Entra family now spans several distinct products beyond the core identity directory: Entra ID for authentication and authorisation, Entra ID Governance for access reviews, entitlement management and identity lifecycle workflows, Entra Permissions Management for cloud infrastructure entitlement management across Azure, AWS and GCP, Entra Verified ID for decentralised identity credentials, and Entra Internet Access and Entra Private Access, which together form Microsoft's Security Service Edge offering as an alternative to traditional VPN-based remote access. For anyone who has worked with Microsoft identity services for a while, the rename is the single most important thing to understand about Entra: existing Azure AD tenants, app registrations, Conditional Access policies, and PowerShell/Graph API objects were not migrated or restructured, they were simply renamed in the portal and documentation, so an organisation's actual tenant, its directory schema, and its licensing (Entra ID Free, P1, P2) carried over directly rather than requiring any technical migration project. This matters practically because a good deal of tooling, scripting, and third-party documentation still refers to "Azure AD," "AAD," or the old module names like AzureAD and MSOnline, and teams working across mixed-vintage documentation need to recognise these as the same underlying service rather than assuming a newer or different product is being described. The commercial reason behind the rebrand was to position identity as the centre of a broader security perimeter that also includes network access, reflecting Microsoft's argument that in a cloud-first, zero-trust world identity and network edge controls need to be managed as one coherent stack rather than as separate identity and networking products bought from different places. For licence and cost management purposes, the practical entity that actually matters remains Entra ID and its P1/P2 tiers, since that is what drives per-user cost and what underpins Conditional Access, multi-factor authentication enforcement, and single sign-on across the rest of the Microsoft 365 and Azure estate; the wider Entra family products are generally separate, additively licensed services that an organisation adopts individually rather than an all-or-nothing suite purchase.

Entra matters because Microsoft 365, Azure, Windows 365, Teams, and related services are usually managed as one estate. The term connects to planning, cost, configuration, security, and day-two operational decisions across that estate.

Security and conformity solutionExplore EtherInsightsWindows 365 and Cloud PC solution
EtherApps ForgeEfficientEther products

EtherApps Forge

EtherApps Forge is EfficientEther's Windows application packaging product, built around a capture-first workflow: it captures a legacy Windows application directly from a running system, recording its files, registry entries, AppData, services, and dependencies, which matters most for the common and difficult case of applications whose original installer media has been lost, is incomplete, or no longer works, since capturing from a live, already-installed instance is often the only practical route left for packaging that application at all. From a single capture, Forge produces multiple deployment-ready outputs rather than locking the output to one format: MSIX for modern Intune deployment, App Attach-ready packages for Azure Virtual Desktop, IntuneWin for standard endpoint delivery, and MSI for legacy targets, so a packaging engineer does not need to repeat the capture process separately for each delivery mechanism an estate still needs to support. Forge also converts existing App-V virtual applications into MSIX, addressing the specific migration pressure many Windows 10 estates face as App-V and older virtualisation approaches are retired in favour of MSIX and App Attach ahead of Windows 11 and Azure Virtual Desktop timelines. A meaningful part of the product's value sits in the compatibility work that MSIX conversion often surfaces: legacy applications frequently misbehave once placed inside MSIX's isolated container, and Forge stages the Package Support Framework, applying file and registry redirection and working-directory fixes, so a captured application runs correctly inside its MSIX package without requiring code changes to the application itself. Signing, manifest fix-ups, and modification packages are handled inline within the same workflow rather than requiring a separate external tool, and embedded AI guidance, built on EtherAssist, supports packaging route decisions and dependency resolution specifically for teams where in-house MSIX expertise is thin, which the product positions as closing a skills gap rather than replacing the packaging engineer's judgement. For teams that already have strong MSIX and scripting capability, Forge exposes a command-line interface, so a build pipeline or an MSP's packaging factory can capture, sign, and produce a deployment-ready MSIX from a single scripted command without touching the GUI at all, and MCP integration allows Forge to be driven directly from AI agents and automation pipelines. The product ships two licence tiers, a GUI-only licence and a full licence that adds PowerShell module and CLI access plus MCP-based AI automation, both priced per admin user per year, is published on the Microsoft Marketplace, and offers a 7-day trial intended to let a team capture and package a real application on day one rather than evaluating the product only through a demo.

EtherApps Forge is part of the EfficientEther portfolio, so the term should point readers to the product or solution route that explains what to do next. The glossary should support discovery, not trap readers on a dead-end definition.

Agentic app packaging solutionMSIX packaging solutionExplore EtherApps Forge
EtherAssistEfficientEther products

EtherAssist

EtherAssist is EfficientEther's secure AI assistant for IT operations, compliance, and MSP teams, built around day-two operational work rather than general-purpose conversation: troubleshooting, documentation, workflow execution, and audit preparation for Microsoft 365 and Azure estates. Its core capability is running multi-step, agentic workflows, tasks broken into stages with scheduling and handoffs between steps, rather than answering a single prompt in isolation, and every run keeps a reviewable history, timestamps, attribution, handoffs, and outputs, so a service desk or an audit team can see exactly what an automated workflow did and confirm it independently rather than trusting the output on faith. Alongside operational workflow execution, EtherAssist includes a distinct compliance-facing capability: a compliance AI assistant that drafts policy sections, reviews gaps against a framework, and prepares audit evidence for standards including ISO 27001, ISO 42001, NIS2, DORA, and SOC 2, generating reviewable draft content with evidence prompts and control references rather than finished, unreviewed policy documents. Day-to-day IT operations use is centred on triage: plain-language incident triage with likely root cause analysis and direct links into the relevant Microsoft admin centre, aimed at reducing repeat escalations by getting a first-line responder to the right diagnosis and the right console faster. The product also generates supporting artefacts commonly needed in Microsoft 365 operations work: rendered diagrams for IT workflows from plain-English prompts, editable Draw.io diagrams that stay modifiable after generation rather than being a flat image, and draft PowerShell scripts for Intune and Microsoft 365 tasks that include comments, sample data, and validation notes, positioned explicitly as reviewable drafts rather than scripts intended to run unreviewed. Trust and data controls are a deliberate part of the product's design rather than an afterthought: customers choose UK, EU, or US hosting for where their data is processed, redaction capability is built in for sensitive context, and EfficientEther states that customer data stays under customer control and is not used for model training, which matters specifically for IT and compliance teams under pressure to use AI without losing control over sensitive tenant and operational information. EtherAssist is also embedded inside EtherInsights, where it generates PowerShell remediation code inline against specific security conformity findings, and inside EtherApps Forge, where it supports packaging route decisions, showing it functions both as a standalone product and as an embedded AI layer across EfficientEther's other tools. Pricing follows a standard per-user monthly subscription for steady rollout, with a metered, token-based plan available for teams with more variable usage, and a 14-day trial with a choice of regional hosting from day one.

EtherAssist is part of the EfficientEther portfolio, so the term should point readers to the product or solution route that explains what to do next. The glossary should support discovery, not trap readers on a dead-end definition.

Explore EtherAssistIT operations and compliance solutionCompare products
EtherInsightsEfficientEther products

EtherInsights

EtherInsights is EfficientEther's platform for Microsoft 365 and Azure cost management, Windows 365 lifecycle support, tenant reporting, user lifecycle operations, security assessment, and Intune device reporting, built as a single operating view rather than a set of separate tools, so cost, Windows 365, security, and device data are queried and presented from one connected product rather than reassembled by hand across several dashboards. On the cost side, it identifies unused Microsoft 365 licences, oversized or idle Azure resources including virtual machines, and Cloud PC cost drift, turning those findings into a savings report with named owners so recommendations have somewhere to go rather than sitting unactioned, and it tracks Microsoft 365 and Azure billing trends over time to surface spikes, dips, and unexplained cost drift before they reach the next invoice. Windows 365 support runs across the full lifecycle, design, deployment, configuration, and day-to-day management of Cloud PCs, including migration baselines for moving from Azure Virtual Desktop to Windows 365, alongside per-Cloud PC insight such as endpoint analytics, startup performance, work-from-anywhere signal, CPU and RAM spike time, and alternative SKU recommendations for rightsizing. Tenant management includes scheduled configuration backup across Entra and Intune, the ability to pin a snapshot as a baseline, drift detection against that baseline, and per-policy restore rather than only a full rollback. Security capability covers Secure Score tracking, Zero Trust pillar assessment, security conformity checks, and Copilot readiness assessment across licensing, sensitivity labels, sharing settings, and data governance, and on the security conformity view specifically, EtherAssist is embedded to generate PowerShell remediation code inline for a selected finding rather than leaving the fix as a separate manual step. User lifecycle functionality covers risky identity detection, onboarding and offboarding, and licence reclaim, and its offboarding capability genuinely executes actions against Microsoft Graph once a user reviews and confirms a run, rather than only reporting what should be done: it revokes active sessions, blocks sign-in, resets password and MFA, cancels meetings, sets a mailbox auto-reply, removes licence assignments, removes group memberships, and removes admin role assignments, with each step logged individually as it completes, is skipped, or fails, giving a per-user task log that can be marked as reviewed and exported as evidence. Intune reporting adds around thirty built-in reports, a per-device detail view, CVE lookup, and the tenant backup and drift detection described above, all inside the same product. EtherInsights is aimed at both direct Microsoft 365 and Azure customers and at partners and MSPs who need to produce the same cost, Cloud PC, posture, and lifecycle evidence pack consistently across every managed tenant without rebuilding it manually per customer, and it is priced publicly per active user with a 14-day trial.

EtherInsights is part of the EfficientEther portfolio, so the term should point readers to the product or solution route that explains what to do next. The glossary should support discovery, not trap readers on a dead-end definition.

Explore EtherInsightsCloud cost optimisation solutionWindows 365 and Cloud PC solution
Evidence captureCompliance

Evidence capture

Evidence capture is the practice of systematically recording, at the point in time an action, decision, or event occurs, the artefacts needed to later prove that it happened, who was responsible, and that it met a required standard, whether that requirement comes from a compliance framework, a contractual obligation, a legal matter, or an internal control. It differs from simply having logs available: logs and audit trails are typically continuous and system-generated, capturing activity as a byproduct of normal operation, whereas evidence capture is often a deliberate, structured act tied to a specific control or process step, such as taking a screenshot and timestamped record of a change approval before a production change is made, retaining the signed output of a joiner-mover-leaver checklist, exporting configuration state before and after a significant change, or preserving the specific report an auditor was shown rather than assuming the same report could be regenerated identically months later. In a Microsoft 365 and Azure context, evidence capture draws on several native sources, Purview audit logs and Entra ID sign-in and audit logs for activity evidence, Intune and Azure Policy compliance reports for configuration state evidence, and Defender and Sentinel incident records for security response evidence, but a mature evidence capture practice does not rely solely on those systems remaining queryable indefinitely; it exports and retains the specific artefacts relevant to defined controls into a separate, durable evidence store, because production system retention windows, licensing changes, or tenant migrations can otherwise silently remove the very evidence a future audit will ask for. This distinction matters most acutely during compliance audits for frameworks like ISO/IEC 27001, SOC 2, and Cyber Essentials Plus, where an assessor testing a specific control, for example that access reviews happen quarterly, or that leavers are deprovisioned within a defined SLA, will typically sample specific instances and expect to see direct evidence of that instance having occurred correctly, not just a policy stating that it should. A frequent and avoidable failure is generating evidence only reactively, at audit time, by reconstructing what probably happened from whatever logs are still available, rather than capturing it as a routine byproduct of the underlying process, which both weakens the evidence's credibility, since contemporaneous records carry more weight than after-the-fact reconstruction, and creates unnecessary audit-season workload. Well-designed evidence capture is therefore usually built into the workflow tooling itself, ticketing systems that require an approval step to be recorded before a change proceeds, automated exports triggered on a schedule, or IT operations platforms that log licence and configuration changes as a structural part of the change itself, so that the evidence exists whether or not anyone remembers to go and gather it later.

Evidence capture matters because customers, resellers, and procurement teams need evidence that controls are defined, operated, and reviewable. A useful glossary definition should help a reader connect the term to audit preparation, policy work, or repeatable assurance activity.

Certifications and securityIT operations and compliance solution
Exchange OnlineMicrosoft cloud

Exchange Online

Exchange Online is Microsoft's cloud-hosted email, calendaring, and contacts service, delivered as part of Microsoft 365 and functioning as the direct cloud successor to on-premises Microsoft Exchange Server, which organisations previously had to install, patch, and maintain their own infrastructure to run. It provides each licensed user with a mailbox accessible through Outlook desktop, Outlook on the web, and mobile clients, along with shared mailboxes, resource mailboxes for rooms and equipment, distribution groups, and the Exchange Admin Center and PowerShell-based Exchange Online Management module used to configure mail flow rules, retention policies, and mailbox permissions. Mailbox storage is licence-tier dependent, with most Microsoft 365 business and enterprise SKUs including 50GB or 100GB mailboxes and unlimited or very large archive storage on higher tiers, and understanding which tier a user is on materially affects both what they can store and what compliance and retention capabilities are available to their mailbox, since features like litigation hold, in-place archiving, and advanced eDiscovery are gated by licence tier rather than universally available. Mail flow and security sit on top of the base mailbox service through Exchange Online Protection, which handles anti-spam and anti-malware filtering for all inbound and outbound mail by default, with Microsoft Defender for Office 365 available as a licensed add-on or included at higher M365 tiers to add safe links, safe attachments, and anti-phishing capabilities that go materially beyond the baseline filtering. A recurring operational and compliance blind spot in mature estates is shared and resource mailbox sprawl: because these mailboxes traditionally did not require a full user licence to create, organisations accumulate large numbers of them for departments, projects, and equipment bookings, and without active review they persist indefinitely, some inactive for years, each one still representing both a storage cost once it exceeds the free-tier size threshold and an access-control surface with permissions that were granted for a project long since finished. Exchange Online's connection to broader Microsoft 365 governance is deep rather than incidental: Microsoft Teams chat and channel data, Microsoft 365 Groups, and Outlook calendar all rely on Exchange Online infrastructure underneath their respective front ends, meaning mailbox-level retention and compliance policies configured in Exchange Online frequently have downstream effects on data retention in services that do not visibly present themselves as email at all, which is a common source of confusion when compliance requirements are being mapped against what looks, from the admin centre, like a single self-contained service.

Exchange Online matters because Microsoft 365, Azure, Windows 365, Teams, and related services are usually managed as one estate. The term connects to planning, cost, configuration, security, and day-two operational decisions across that estate.

Windows 365 and Cloud PC solutionExplore EtherInsights

F

FinOpsCommercial and channel

Cloud financial operations

FinOps is the operating discipline for managing cloud cost through shared visibility, ownership, optimisation, forecasting, and accountability across engineering, finance, and business teams, rather than treating cost as a finance-only concern discovered after the invoice lands. The practice is usually described in three phases that repeat: Inform, where teams get accurate, allocated visibility into what is being spent and by whom; Optimise, where that visibility turns into concrete action such as rightsizing, commitment purchases, or licence reclaim; and Operate, where the organisation builds the recurring habits, ownership model, and governance that keep the first two phases from decaying back into an unmanaged bill. On a Microsoft estate, FinOps spans two cost surfaces that are often managed separately but should not be: Azure consumption, covering compute, storage, and networking, and Microsoft 365 licensing, covering per-seat subscription spend. Treating them as one discipline matters because the same waste pattern, capacity provisioned for a need that no longer exists, shows up in both: an oversized virtual machine and an unused Premium licence are the same underlying failure, just on different bills. A mature FinOps practice depends on cost allocation actually working, since a team cannot be accountable for spend it cannot see attributed to it, and on a regular review cadence, often a monthly reclaim and rightsizing pass paired with a quarterly business review, so cost control is a habit rather than an annual scramble triggered by a budget overrun. The discipline also has to survive organisational reality: engineering teams optimise for delivery speed, not cost, unless cost is made visible and owned at the point decisions are made, which is why FinOps practitioners spend as much effort on tagging, showback, and dashboards as they do on the technical optimisations themselves. For a managed service provider, FinOps additionally means doing this consistently across many customer tenants rather than reinventing the review process for each one, which is where tooling that surfaces licence waste, idle Azure resources, and rightsizing evidence in one place earns its keep over a spreadsheet rebuilt every month.

FinOps matters because Microsoft estate decisions often have a commercial owner as well as a technical owner. Clear cost, licence, and partner language helps teams prove value, reclaim waste, and agree the next action before spend becomes harder to challenge.

Explore EtherInsightsCloud cost optimisation solutionWindows 365 and Cloud PC solution

G

GDPRCompliance

General Data Protection Regulation

The General Data Protection Regulation is the European Union's data protection framework, governing how organisations collect, process, store, protect, and disclose personal data belonging to individuals in the EU, built around a defined set of core principles: lawfulness, fairness and transparency in how data is used; purpose limitation, meaning data collected for one stated purpose should not simply be reused for an unrelated one without a fresh lawful basis; data minimisation, collecting only what is genuinely needed rather than accumulating data speculatively; accuracy; storage limitation, meaning personal data should not be retained indefinitely once its original purpose no longer requires it; and integrity and confidentiality, the security obligation to protect data against unauthorised access, loss, or damage. GDPR grants individuals, referred to as data subjects, specific enforceable rights over their own data, including the right of access to obtain a copy of data held about them, the right to rectification of inaccurate data, the right to erasure in defined circumstances, often called the right to be forgotten, and the right to data portability, and organisations processing personal data need documented, workable processes actually capable of honouring these rights within the regulation's response deadlines, not merely a policy stating that they will. A distinction that matters operationally is between a data controller, the organisation that determines why and how personal data is processed, and a data processor, an organisation that processes data on the controller's behalf and instruction, such as a cloud or software vendor; the two roles carry different specific obligations, and a single organisation is frequently both simultaneously for different data sets it handles. Since the UK's departure from the EU, GDPR as such no longer applies directly within the UK; a near-identical framework, UK GDPR, now governs data processing carried out within the UK specifically, and organisations operating across both jurisdictions need to track compliance against both frameworks, since they are closely aligned in substance but are legally distinct instruments that can diverge over time.

GDPR matters because customers, resellers, and procurement teams need evidence that controls are defined, operated, and reviewable. A useful glossary definition should help a reader connect the term to audit preparation, policy work, or repeatable assurance activity.

Certifications and securityIT operations and compliance solution