Conditional Access
Conditional Access is Microsoft Entra ID's policy engine for making real-time access decisions, evaluating signals about who is signing in, from what device, from where, into which application, and at what assessed risk level, then applying a grant control before the sign-in is allowed to complete. A policy is built from an if-then structure: assignments define the conditions under which it applies, such as a specific group of users, a specific set of cloud apps, a named location, or a device platform, while grant controls define what must additionally be satisfied, such as requiring multifactor authentication, requiring a compliant or hybrid-joined device, requiring an approved client app, or blocking access outright, and session controls can further restrict what happens after access is granted, such as limiting app functionality through Conditional Access App Control or forcing frequent reauthentication for sensitive apps. This is what makes Conditional Access the practical enforcement layer of a Zero Trust posture: rather than trusting a session simply because it presented a valid password, every sign-in is re-evaluated against current context, and Identity Protection's risk signals can feed directly into policy, automatically requiring stronger verification or blocking sign-in entirely when a user or sign-in is flagged as risky. In practice, the two things that most commonly go wrong are policy conflicts and scope gaps: overlapping policies with contradictory controls can produce unexpected blocks or unintended bypasses, and it is disturbingly easy to build a policy that technically applies to 'all users' but inadvertently excludes a service account, a break-glass account, or a legacy authentication path that still bypasses modern authentication entirely, which is exactly the kind of gap attackers look for. Because a misconfigured policy can lock out an entire tenant, including its own administrators, maintaining at least one emergency-access 'break-glass' account excluded from Conditional Access, with a long, closely guarded credential, is standard practice rather than an optional precaution, and new or modified policies should generally be rolled out in report-only mode first so their real-world impact on existing sign-ins can be reviewed before enforcement begins. Conditional Access itself requires an Entra ID P1 licence or equivalent bundled entitlement, and it sits alongside Multifactor Authentication, device compliance from Intune, and Identity Protection's risk detections as one of the core building blocks that turns identity, rather than the network perimeter, into the primary control point for access decisions.
CA 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.
Digital certificate
A digital certificate is a cryptographically signed file that binds a public key to an identity, verified and issued by a certificate authority that both parties trust, and in a Microsoft application packaging and deployment context its most immediate relevance is as the code signing certificate that every MSIX package must be signed with before Windows will install it. The certificate establishes who published a package and gives Windows a basis for trust decisions: an MSIX signed with a certificate chaining to a public, trusted root can be installed and updated without additional warnings, one signed with a self-signed or internally issued certificate requires that certificate's root to be explicitly trusted on the target device first, typically by deploying it to the device's trusted root or trusted people store through Group Policy or Intune, which is the normal arrangement for line-of-business applications sideloaded within an organisation rather than distributed through the Microsoft Store. Certificates carry an expiry date, and this is one of the most common operational failures organisations hit with signed packages: once a signing certificate expires, packages signed with it can no longer be freshly installed or, depending on configuration, updated, even though previously installed instances usually continue running, which is why certificate renewal needs to be tracked as an active lifecycle item rather than discovered only when a deployment starts failing. Timestamping a signature at the point of signing mitigates part of this problem by allowing Windows to treat the signature as valid based on when the package was signed rather than the current date, so a package signed before the certificate expired can still be trusted as validly signed after expiry, provided the signing process included a trusted timestamp. Beyond code signing, certificates also appear throughout a Microsoft estate in other trust contexts relevant to the same teams: TLS certificates securing the endpoints an App Installer file or update feed is hosted on, client certificates used for device or user authentication, and certificates backing conditional access and device compliance policies. Getting certificate management right in a packaging context specifically means tracking issuance, expiry, and the specific publisher name embedded in the certificate's subject, since MSIX package identity is tied to that publisher name and changing certificates without matching the publisher name breaks update continuity for already-installed packages, and knowing where the root of trust needs to be distributed for it to actually be usable.
Certificate 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.
CI/CDPlatform and integration Continuous Integration and Continuous Delivery
Continuous Integration and Continuous Delivery is the practice of building, testing, and preparing software changes through automated, repeatable pipelines rather than manual, ad hoc release steps, so that every change is validated the same way before it reaches production. Continuous Integration is the first half: developers merge code changes frequently, and each merge automatically triggers a build and a test suite, catching integration problems and regressions within minutes rather than at the end of a release cycle when they are far more expensive to trace back to their cause. Continuous Delivery extends that automation through packaging, staging deployment, and release readiness, so a validated change can reach production through a controlled, auditable pipeline rather than a manual copy-and-run process; some teams take the further step of Continuous Deployment, where a change that passes every gate ships automatically with no manual approval, though most regulated or enterprise environments keep a manual or policy-gated approval step before production for exactly the audit and change-control reasons that matter in Microsoft 365 and Azure estates. In application packaging and Windows modernisation work specifically, CI/CD is what turns MSIX, MSI, or IntuneWin packaging from a one-off manual task into a repeatable factory process: a packaging pipeline can pull a build artefact, run it through capture and conversion, sign the output, validate it against best-practice checks, and push it to Intune for staged rollout, all triggered by a commit or a scheduled job rather than an engineer manually repeating the same steps for every application version. This is also where command-line and API-driven tooling earns its value over GUI-only products, since a pipeline step needs a script or an API call it can invoke unattended, not a person clicking through a wizard; a packaging tool that exposes a CLI and supports MCP or REST automation can be wired directly into an existing build pipeline, while a GUI-only tool forces a manual handoff that breaks the automation chain and reintroduces the inconsistency CI/CD exists to remove. For MSPs and packaging factories managing many customer estates, this matters at scale: a standardised pipeline applied consistently across every customer produces predictable, auditable outputs, whereas repeating manual packaging steps per customer both costs more engineering time and introduces the kind of estate-by-estate inconsistency that later shows up as configuration drift or as failed deployments that are hard to diagnose because no two builds followed exactly the same steps. Version control integration, build artefact retention, and pipeline logs also double as the evidence trail auditors and compliance reviewers look for, since a CI/CD pipeline that recorded what changed, when, and under what approval is inherently more defensible than a change nobody can reconstruct after the fact.
CI/CD matters because integrations, APIs, virtual machines, and delivery pipelines are how Microsoft estate data and automation become usable. These terms help readers understand how systems connect before they decide what to build or automate.
CIMApplication modernisation Composite Image File System
CIM, the Composite Image File System, is the container image format that sits underneath an installed MSIX package, and it is the specific mechanism that makes MSIX's fast, low-footprint install and mount behaviour possible. Rather than copying every file in a package onto disk during installation the way a traditional installer does, MSIX packages are stored as a CIM image, a single-instance, content-addressed, read-only image format, and mounted directly through the cimfs.sys filesystem driver built into Windows, so the application's files appear on disk without a full file-by-file copy operation having to complete first. This is what allows an MSIX install to complete in a fraction of the time a comparable traditional installer takes, and it is also the underlying technology behind CimFS-based App Attach on Azure Virtual Desktop and Windows 365, where a CIM image containing an application is attached to a user's session at logon rather than the application being pre-installed into every session host image. Single-instancing at the CIM layer means that identical file content across packages, or across multiple versions of the same package, can be stored once rather than duplicated, which keeps the storage footprint of an application library smaller than the equivalent set of full installations would be, a genuinely material consideration for organisations running App Attach at scale across large AVD or Windows 365 estates where storage and mount performance both affect user logon time. CIM has effectively superseded VHDX as the preferred container for newer App Attach deployments because it mounts faster and avoids the fixed or dynamic disk overhead that a virtual hard disk format carries, though VHDX-based App Attach remains in active use and is still fully supported, particularly in estates that adopted App Attach before CimFS-based delivery matured or where tooling has not yet been updated to the newer format. For anyone building or troubleshooting an application streaming or attach pipeline, the practical implication is that CIM is not something packagers interact with directly the way they interact with an MSIX manifest or a certificate; it operates transparently underneath the package format, but its presence explains observable behaviour such as why an MSIX application can appear to be available almost immediately after attach, why disk usage for a library of similar packages is lower than expected, and why troubleshooting a slow or failed attach sometimes needs to consider the CIM mount layer itself rather than only the package or the application inside it.
CIM 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.
Cloud PC
A Cloud PC is a Windows desktop hosted by the Windows 365 service and streamed to a user on supported devices, provisioned and managed through Intune policy rather than manually built and configured by an administrator the way a traditional VDI desktop typically is. The defining characteristic of a Cloud PC is persistence and dedication: unlike a pooled Azure Virtual Desktop session, where a user connects to whichever available host in a shared pool has capacity, a Cloud PC is assigned one-to-one to a single named user and behaves like a personal, always-there desktop, keeping its state, installed applications, and configuration between sessions rather than resetting. Provisioning is driven by policy rather than manual build: an administrator defines a provisioning policy specifying the image, network configuration, and region, assigns it to a user group through Entra ID, and Windows 365 automatically creates and configures the matching Cloud PC for every member of that group, which is what makes the model scale cleanly across a large estate without per-user manual setup. Sizing is expressed directly in vCPU, RAM, and storage, published as a fixed monthly per-user price rather than the variable consumption billing of Azure Virtual Desktop, which is the core trade-off between the two: a Cloud PC gives predictable, easy-to-forecast cost and near-zero infrastructure administration, in exchange for less granular control over the underlying compute than a self-managed Azure Virtual Desktop host pool provides. Data residency for a Cloud PC is controlled through the same provisioning policy that sets the image, since it also determines the Azure region the Cloud PC is created in, which matters for organisations with specific regional or UK data residency requirements. Because a Cloud PC is genuinely persistent, FSLogix profile management, commonly required to make user state portable across shared or pooled AVD session hosts, is largely unnecessary; the user's state already lives with their dedicated machine. This combination of policy-driven provisioning, one-to-one persistence, and flat per-user pricing is what makes Cloud PC estates well suited to standard knowledge-worker cohorts with predictable, steady usage, while cohorts with more variable, shift-based, or specialist compute needs are usually better served by Windows 365 Flex or Azure Virtual Desktop instead.
Cloud PC 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.
Cloud PC sizing
Cloud PC sizing is the process of selecting the virtual hardware configuration, vCPU count, RAM, and storage size, assigned to a Windows 365 Cloud PC through its licence SKU, and getting it right is one of the highest-leverage cost decisions in a Windows 365 deployment because, unlike Azure Virtual Desktop's pay-as-you-go compute, Windows 365 Cloud PCs are billed as a fixed monthly per-user, per-configuration fee regardless of actual utilisation, meaning an oversized Cloud PC is pure ongoing waste rather than a cost that only materialises under load. Microsoft publishes a defined set of standard configurations, ranging from 2 vCPU/8GB RAM entry configurations intended for light task-worker use, through 4 vCPU/16GB mid-tier configurations suited to typical knowledge-worker productivity workloads, up to 8 vCPU/32GB and higher configurations aimed at power users running demanding applications such as CAD software, data analysis tools, or heavy multitasking across many concurrent apps, with storage sized separately in fixed increments from 128GB up to 2TB. The core sizing challenge is that these are static assignments made at provisioning time, generally by user group or job role, rather than dynamic allocations that respond to actual usage, so a Cloud PC sized for the busiest day a user might have will run at that cost every day of the month even when idle, and the most common real-world sizing mistake is defaulting an entire organisation, or an entire department, to one generous configuration for administrative simplicity rather than matching configuration tiers to actual role-based workload profiles. Microsoft does provide a resize capability that lets an administrator change a provisioned Cloud PC's configuration without a full reprovision, and Windows 365 usage reports inside the Intune admin centre surface actual CPU, memory, and disk utilisation per Cloud PC over time, which is the primary evidence base for identifying oversized assignments, since utilisation well below the provisioned configuration's ceiling over a sustained period is a strong and low-risk signal that a smaller, cheaper SKU would serve the same user without a perceptible difference in experience. The reverse risk, undersizing, matters just as much operationally even though it does not show up as wasted spend: a Cloud PC sized too small for its user's actual workload produces poor day-to-day performance, application slowdowns, and a stream of help desk tickets that often gets misdiagnosed as a network or application problem rather than correctly traced back to an inadequate compute allocation, so sizing review is properly a two-directional exercise, catching both wasted spend on oversized Cloud PCs and hidden productivity cost from undersized ones, rather than a cost-cutting exercise alone.
Cloud PC sizing 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.
Code signing
Code signing is the process of applying a cryptographic signature, generated from a digital certificate and its private key, to an executable, script, or package so that the operating system and the people running it can verify who published it and confirm it has not been altered since signing. MSIX makes code signing a mandatory part of the format rather than an optional best practice the way it is for a traditional EXE or MSI: Windows will not install an MSIX package at all unless it carries a valid signature chaining to a certificate trusted on that device, which closes off a whole category of tampering and impersonation risk that unsigned or optionally-signed installers have always been exposed to, but which also means a packaging pipeline cannot treat signing as a late, occasional step; every build that needs to reach a device has to be signed as part of the release process. The signing identity matters as much as the act of signing itself: the publisher name in the certificate becomes part of the package's identity, so switching signing certificates, letting one certificate expire and replacing it with a differently-issued one without matching the subject name, or signing a supposedly-updated package with a different certificate than the original, breaks the update chain for devices that already have the earlier version installed, since Windows treats it as effectively a different, unrelated application rather than an update. Timestamping a signature at signing time protects against the most common operational failure mode: without a trusted timestamp, a package's signature becomes invalid the moment its signing certificate expires, whereas a timestamped signature remains valid because it can be evaluated against the certificate's validity at the time of signing rather than the current date, which is why timestamping should be treated as a default rather than an optional signing setting. For applications distributed publicly rather than sideloaded within an organisation, the certificate's reputation also interacts with Windows SmartScreen and broader trust heuristics, where a newly issued or low-reputation certificate can trigger warnings even though the signature itself is technically valid, an effect that only fades as the certificate accumulates a track record of signing software that behaves well, which is one of several reasons organisations distributing software externally often prefer an Extended Validation code signing certificate over a standard one, since EV certificates carry stronger identity verification and tend to build reputation faster.
Code signing 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.
Microsoft Intune compliance policy
An Intune compliance policy defines the minimum security and configuration standard a device must meet to be considered "compliant," evaluating conditions such as minimum OS version, BitLocker or disk encryption status, whether the device is jailbroken or rooted, password or PIN complexity, whether real-time antivirus protection is active, and Secure Boot or TPM presence, and then reporting a pass or fail state per device back into Intune and Entra ID. Compliance policies are not, by themselves, an enforcement mechanism; a device that fails a compliance check is simply marked non-compliant, and nothing stops that device from continuing to operate unless a separate Conditional Access policy is configured to require compliance as a condition of accessing corporate resources like Exchange Online, SharePoint, or Teams, which is the connection that trips up a lot of first-time Intune deployments, since it's entirely possible to build a thorough set of compliance policies that have no actual effect on anything because the Conditional Access side was never wired up. Policies are assigned per platform, since the settings available and how they're evaluated differ meaningfully between Windows, iOS/iPadOS, Android, and macOS, and per Entra ID group, and a device can be in scope for more than one compliance policy simultaneously, in which case Intune applies the strictest evaluated result across all applicable policies rather than the most recently assigned one, a behaviour that surprises admins who expect the newest or most specific policy to simply override an older, broader one. Grace periods, the window a newly non-compliant device is given before it's actually marked non-compliant in reporting and Conditional Access enforcement, are a common source of a device appearing compliant in the console while genuinely failing a check, since the grace period exists specifically to avoid immediately locking out a user for a transient issue like a delayed policy sync, but it also means compliance dashboards can lag real device state by hours or days depending on configuration. Compliance policies also support "compliance actions for noncompliance," configurable notifications and, after a further grace period, automatic remote actions, the mechanism organisations use to nudge users toward self-remediation, sending an email or push notification when a device first goes non-compliant, before Conditional Access starts actively blocking access, rather than the block being the user's first indication anything was wrong. Because compliance status feeds directly into access decisions, compliance policy is one of the highest-leverage places in an Intune estate for both security and cost review: a large population of devices sitting permanently non-compliant, whether from genuine security gaps, stale policy assignments no longer matching the actual device fleet, or devices that have effectively left the estate without being retired, represents both an unmanaged risk and, often, licensed seats no longer delivering the governance they're being paid for.
Compliance 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.
Microsoft Intune configuration profile
A configuration profile is the mechanism Intune uses to push settings onto enrolled devices, covering areas like Wi-Fi and VPN connection settings, certificate deployment, device restrictions such as disabling the camera or USB storage, email profile configuration, kiosk mode, and a very broad range of Windows, iOS/iPadOS, macOS, and Android-specific settings that would previously have been delivered through Group Policy Objects, Apple Configurator, or Android Enterprise's own management console. Under the hood, most Windows configuration profile settings are delivered through Configuration Service Providers, CSPs, the same underlying mechanism Windows itself exposes for MDM-based configuration, and Intune offers two overlapping ways to build them: templated profiles, which present a curated, purpose-built set of settings for a specific scenario such as Wi-Fi or endpoint protection, and the Settings Catalog, which exposes the full, granular list of available CSP settings directly and is now Microsoft's preferred approach for new profile creation since it's kept current with new CSPs as they're released, whereas some older templates have been deprecated or are missing newer settings entirely. Profiles are assigned to Entra ID groups, and because a device or user can be in scope for multiple profiles simultaneously, from different admins targeting different groups over time, conflicting settings between profiles are one of the most common and hardest to diagnose problems in a mature Intune estate: two profiles each setting the same underlying CSP to a different value produces a conflict that Intune reports but doesn't resolve automatically, and the device will show that specific setting as being in a conflict or error state until an admin identifies and resolves the overlap, which without deliberate profile naming conventions and a clear map of what each profile targets can take real investigation to track down. Configuration profiles are distinct from, but easily confused with, compliance policies and endpoint security policies: a configuration profile enforces a setting by directly configuring the device, while a compliance policy only checks whether a state is true and reports pass or fail without independently changing anything, and endpoint security policies are really configuration profiles in effect but exposed through a separate, security-focused part of the console covering areas like disk encryption, firewall, and antivirus specifically. In practice, configuration profile sprawl, dozens of overlapping profiles built up over years by different admins, some targeting groups that no longer reflect current organisational structure, is one of the more common and less visible sources of operational risk and troubleshooting overhead in long-running Intune tenants, and periodic profile audits, consolidating overlapping profiles and retiring ones targeting stale or empty groups, is standard estate hygiene rather than a one-off migration task.
Configuration profile 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.
Microsoft 365 Copilot
Microsoft 365 Copilot is Microsoft's generative AI assistant embedded directly into the Office and Teams applications, Word, Excel, PowerPoint, Outlook, Teams, and the standalone Copilot Chat experience, using large language models combined with the Microsoft Graph to answer questions, draft and summarise content, and generate insights grounded in a user's own emails, documents, meetings, and chats rather than only general knowledge. Its defining architectural feature, and the one with the most direct operational consequence for IT teams, is that Copilot answers strictly within the data a given user can already access through their existing Microsoft 365 permissions: it does not grant new access to anything, but it also does not add any new restriction beyond what already exists, which means Copilot is only as safe as an organisation's underlying SharePoint, OneDrive, and Teams permission model already was, and years of accumulated over-sharing, broad "Everyone except external users" links, stale site permissions, oversized security groups, that were a low, mostly theoretical risk when finding an over-shared file required someone to manually search for it become a materially higher risk once Copilot can synthesise and surface that same content instantly in response to a normal question. This is why Copilot rollouts that skip a permissions and data governance review before enabling licences are one of the most consistently flagged mistakes in early Microsoft 365 Copilot deployments, and Microsoft Purview's sensitivity labelling, data loss prevention, and the specific Copilot-related oversharing assessment tooling exist largely to close that exact gap before, rather than after, Copilot is switched on broadly. Licensing is a distinct commercial consideration from the AI features bundled into other Microsoft 365 tiers: Microsoft 365 Copilot is a separate per-user add-on licence on top of an existing qualifying Microsoft 365 plan, priced at a level that makes usage justification a genuine ongoing question rather than a one-off purchasing decision, and adoption tracking, whether licensed users are actually using Copilot regularly across the apps it's enabled in, is one of the more common areas where organisations discover meaningful licence waste months after a rollout, since it's straightforward to assign a Copilot licence during onboarding and considerably less straightforward to notice, without deliberate usage reporting, that a meaningful share of licensed users never adopted it. Copilot also exists in variants beyond the core Microsoft 365 experience worth distinguishing, including Copilot Chat, a lighter-weight, more limited experience available without the full per-user Copilot licence, and Copilot Studio, a separate product for building custom agents rather than the assistant itself, and conflating these different Copilot products during budgeting or planning is a common and avoidable source of licensing confusion.
Copilot matters when teams want AI support without losing control of identity, data, approvals, and audit evidence. In the EfficientEther portfolio, AI terms usually connect to governed workflows, Copilot readiness, or agentic packaging where humans still review important outputs.
Microsoft 365 Copilot readiness
Copilot readiness is the assessment of whether an organisation's licensing, data governance, permissions, sensitivity labels, sharing posture, and operational controls are genuinely prepared before a Microsoft 365 Copilot rollout, rather than treating readiness as satisfied simply because the licences have been purchased. The reason this assessment matters more for Copilot than for a typical software rollout is that Copilot answers questions using whatever content the requesting user already has permission to access across SharePoint, OneDrive, Teams, and Exchange, which means any pre-existing oversharing, files or sites with broader access than intended, becomes immediately and directly discoverable through natural-language prompts in a way it was not when finding that content required manually browsing to it. A genuine readiness assessment therefore checks several distinct signals rather than a single licence count: permissions and sharing posture, specifically identifying SharePoint sites and OneDrive locations with unintentionally broad access such as organisation-wide or anonymous links; sensitivity label coverage and whether Microsoft Purview auto-labelling is active on content that should be restricted; oversharing remediation tooling such as SharePoint Advanced Management and Restricted SharePoint Search, which can scope what Copilot is allowed to surface without necessarily changing underlying permissions; and data governance maturity more broadly, since Copilot outputs are only as trustworthy as the content and metadata feeding them. Two distinct assessment postures exist in the market and it is worth being clear which is being asked for: a general assessment aimed at any single organisation's own tenant, and an MSP-productised assessment aimed at running the same readiness check consistently and profitably across many customer tenants, which typically demands white-labelling, multi-tenant reporting, and a repeatable remediation playbook rather than a one-off consulting engagement. Readiness is not a single pass or fail gate crossed once before go-live; oversharing and label drift continue to accumulate as an estate keeps changing after rollout, which is why the more defensible organisations treat Copilot readiness as a recurring review rather than a project completed and then forgotten.
Copilot readiness matters when teams want AI support without losing control of identity, data, approvals, and audit evidence. In the EfficientEther portfolio, AI terms usually connect to governed workflows, Copilot readiness, or agentic packaging where humans still review important outputs.
Cost allocation
Cost allocation is the FinOps practice of assigning shared or consolidated cloud spend back to the teams, services, customers, projects, or business owners actually responsible for it, so that a single Azure invoice or Microsoft 365 bill can be broken down into figures specific teams can be held accountable for, rather than remaining one anonymous total nobody individually owns. In Azure this is done primarily through resource tags: metadata attached directly to a resource, such as owner, environment, project, or cost centre, that Cost Management can use to filter and group spend. The detail that catches most teams out is that a cost record only carries a tag if that tag was applied directly to the resource itself; tags are not implicitly inherited from a parent resource group in cost data, and some resource types do not emit tags into cost records at all, so a tagging strategy has to be actively enforced, typically with Azure Policy, rather than assumed to work automatically once a naming convention is agreed. A workable minimum tag set is usually small and consistently enforced rather than large and routinely ignored: an owner tag naming the accountable person or team, an environment tag distinguishing production from non-production or development, and often a project or cost-centre tag for chargeback purposes. Anything left untagged becomes unattributable spend: it appears in the total but cannot be split by team, environment, or project, which quietly undermines FinOps accountability no matter how good the optimisation work elsewhere is, because a team cannot be expected to control cost it cannot see attributed to itself. On the Microsoft 365 side, cost allocation works differently, typically through group-based licensing and department or cost-centre mapping in the admin centre rather than resource tags, but the underlying goal is identical: connect spend to an owner who can make an informed decision about whether it is still justified. Effective cost allocation is what makes a QBR or savings report credible, since a saving reported against an anonymous total invites scepticism, while a saving reported against a named owner's allocated spend is evidence.
Cost allocation 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.
CSPCommercial and channel Cloud Solution Provider
CSP, Cloud Solution Provider, is Microsoft's partner programme through which organisations buy and manage their Microsoft cloud subscriptions, Microsoft 365, Azure, Dynamics 365, and Windows 365 among them, via a partner rather than directly from Microsoft, with that partner handling billing, provisioning, and a defined level of ongoing support as part of the relationship. The programme has a tiered structure: an Indirect CSP reseller sells through an Indirect Provider that holds the direct billing relationship with Microsoft and takes on much of the operational and technical infrastructure, while a Direct CSP partner bills the customer itself and carries a correspondingly higher bar of Microsoft-set competency and support requirements, and the distinction genuinely matters to a customer because it shapes who they actually escalate a billing or licensing issue to and how much flexibility exists in adjusting a subscription outside a renewal cycle. Compared with an Enterprise Agreement, CSP billing is typically monthly rather than committed to a multi-year term, which in principle gives customers more flexibility to adjust licence counts and mix as needs change, but that flexibility is genuinely useful only if the customer, or their CSP partner on their behalf, actually monitors usage and acts on it, since CSP's monthly cadence does nothing by itself to prevent an organisation quietly accumulating unused or oversized licences the way annual, less frequently reviewed agreements often do. This is precisely where licence visibility and cost-optimisation tooling earns its keep in a CSP relationship: identifying inactive accounts, oversized SKUs, and licence types that no longer match actual usage turns CSP's monthly billing flexibility into monthly cost savings rather than a theoretical advantage that goes unrealised because nobody is reviewing consumption between renewals. It is also worth being precise that a CSP partner and a Managed Service Provider are related but distinct roles that are frequently, though not always, held by the same company: CSP describes a licensing and billing channel relationship with Microsoft specifically, while MSP describes a broader IT service delivery model that may or may not involve reselling Microsoft licensing at all, and understanding which hat a given partner is wearing in a specific conversation, licensing reseller, technical support provider, or both, matters when working out who is actually accountable for a specific cost, configuration, or support issue.
CSP 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.
Custom Windows image
A custom Windows image, in the context of Azure Virtual Desktop and Windows 365, is a pre-configured virtual machine image, built by an organisation rather than taken directly from the Microsoft-provided gallery, that bakes in applications, settings, and configuration so that every new session host or Cloud PC provisioned from it arrives in a consistent, ready-to-use state instead of a generic out-of-box Windows installation requiring post-deployment configuration. The alternative to a custom image is using one of Microsoft's Azure Marketplace gallery images directly, which is faster to get started with and requires no image maintenance, but leaves every application installation, Office activation, group policy configuration, and line-of-business tool deployment to run at first sign-in or through a separate post-provisioning configuration profile, which is workable at small scale but becomes slow and inconsistent as session host or Cloud PC count grows into the hundreds. Building a custom image typically starts from a Microsoft-provided base image (commonly the multi-session enabled Windows 11 Enterprise editions purpose-built for Azure Virtual Desktop, or standard Windows 11 Enterprise for Windows 365) and layers on required applications, removes unwanted default apps and services to reduce boot time and resource consumption, applies organisational branding and default settings, and is then captured, generalised with sysprep, and published as a versioned image in an Azure Compute Gallery for reuse across provisioning policies and host pools. Image versioning and lifecycle management is where custom images demand ongoing operational discipline rather than being a one-off build task: Windows security updates, application version updates, and configuration changes all need to be rolled into new image versions on a defined cadence, and an organisation that builds one image and never revisits it accumulates a growing patch and update burden that then has to be caught up in a single disruptive pass, or worse, gets pushed onto post-deployment configuration profiles running redundant work at every sign-in that a properly refreshed image would have avoided entirely. The performance and cost implications of image quality are genuinely significant at scale: a bloated image carrying unnecessary background services, unneeded default Windows apps, or inefficient application installations directly increases boot time, per-session resource consumption on Azure Virtual Desktop's shared multi-session hosts, and effective Cloud PC sizing requirements on Windows 365, so image hygiene is not a cosmetic concern but a direct lever on both compute cost and end-user experience across every host or Cloud PC provisioned from that image.
Custom image 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.
Common Vulnerabilities and Exposures
Common Vulnerabilities and Exposures is a standardised naming system for publicly disclosed software and hardware vulnerabilities, maintained by MITRE under a programme sponsored by the US Department of Homeland Security's CISA, with individual vulnerabilities assigned a unique identifier in the format CVE-YYYY-NNNNN by an accredited CVE Numbering Authority, which for Microsoft products is generally Microsoft itself, working through its Security Response Center. The identifier's job is deliberately narrow: it provides a single, unambiguous reference for a specific vulnerability so that vendors, researchers, and security tools can all discuss and track the same issue without ambiguity, and it carries no severity information on its own, which is why CVEs are almost always paired with a CVSS score, a numeric severity rating from 0 to 10 built from factors like attack complexity, required privileges, and potential impact, giving organisations a common basis for prioritising remediation across an otherwise unmanageable volume of disclosed vulnerabilities. In a Microsoft-managed estate, CVE tracking connects directly into the monthly Patch Tuesday cycle, where Microsoft publishes security updates addressing that month's batch of disclosed CVEs affecting Windows, Office, and other Microsoft products, each with its own advisory detailing affected versions, severity, and whether active exploitation has already been observed in the wild; a CVE actively being exploited before or shortly after disclosure is generally referred to as a zero-day, and these carry materially higher urgency than a CVE with no known exploitation, even if their raw CVSS score is similar. Vulnerability management tooling, such as Defender Vulnerability Management within the Defender for Endpoint suite, continuously inventories software versions across managed devices and cross-references them against known CVEs, surfacing which endpoints are actually exposed to a given vulnerability rather than leaving that as a manual spreadsheet exercise, and CISA's Known Exploited Vulnerabilities catalogue adds a further prioritisation layer by explicitly flagging which CVEs have confirmed real-world exploitation, which is often a more actionable signal for triage than CVSS score alone, since a lower-scored CVE under active exploitation is frequently a more urgent remediation priority than a higher-scored one that remains only theoretical. Patch and vulnerability management timeliness is also a direct compliance requirement under frameworks like Cyber Essentials, which specifically expects security updates to be applied within a defined window of release, meaning an organisation's CVE remediation cadence is not purely a technical housekeeping matter but something that can be checked, questioned, and, in procurement or insurance contexts, required as evidence before a contract or policy is agreed.
CVE 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.
Cyber Essentials certification
Cyber Essentials is a UK government-backed certification scheme, overseen by the National Cyber Security Centre and delivered operationally through IASME as the appointed delivery partner, that checks a defined set of basic technical controls proven to protect organisations against the most common internet-based cyber attacks. The scheme deliberately does not attempt to cover every possible security control; it focuses on five specific technical areas chosen because they close the attack paths most commonly exploited in practice: firewalls and internet gateways controlling network traffic at the boundary, secure configuration removing unnecessary default accounts and settings on devices and software, user access control ensuring accounts and administrative privilege are granted only where genuinely needed, malware protection, and security update management ensuring software and operating systems are patched promptly rather than left exposed to known, already-fixed vulnerabilities. Certification is achieved through a self-assessment questionnaire, verified by an accredited certification body, and it needs renewing annually, since the controls being checked and the threat landscape they are meant to counter both continue to evolve. For UK organisations, Cyber Essentials has become a genuinely practical commercial requirement rather than a purely voluntary security exercise: it is mandatory for suppliers bidding on many UK government contracts, and it has increasingly become an implicit baseline expectation in wider commercial procurement and cyber insurance underwriting, meaning failing to hold current certification can function as a real, immediate barrier to specific revenue rather than only a theoretical security gap. The assurance level is important to be precise about: standard Cyber Essentials certification is based on self-assessment, verified by the certification body reviewing the submitted questionnaire responses rather than independently testing the organisation's actual systems, which is the exact gap the higher-assurance Cyber Essentials Plus adds through independent technical verification, and organisations should be clear about which level a specific customer, contract, or insurer is actually asking for before assuming standard certification is sufficient.
Cyber Essentials 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.
Cyber Essentials Plus certification
Cyber Essentials Plus is the higher-assurance tier of the Cyber Essentials scheme, covering the same five technical control areas, firewalls and internet gateways, secure configuration, user access control, malware protection, and security update management, but replacing standard Cyber Essentials' self-assessment questionnaire with independent, hands-on technical verification carried out by a certification body assessor. Where standard certification is based on an organisation truthfully answering a set of questions about its own controls, Cyber Essentials Plus involves an assessor actually testing a representative sample of the organisation's devices and systems directly, including vulnerability scanning, checks that patches have genuinely been applied rather than merely scheduled, and verification that malware protection is actively running and correctly configured rather than simply installed, which closes the gap between what an organisation believes about its own security posture and what independent testing actually confirms. This distinction matters commercially as much as technically, since certain sectors, contracts, and cyber insurance underwriters specifically require Cyber Essentials Plus rather than accepting standard certification, treating the independent verification as materially stronger assurance that the claimed controls are genuinely operating in production rather than only on paper, and an organisation should confirm precisely which tier a given customer or contract requires before assuming standard certification will satisfy it. Preparing successfully for Cyber Essentials Plus generally means the underlying technical controls need to already be operating consistently in practice, not merely documented as policy, since an assessor testing live systems will surface any gap between the two, which makes achieving standard Cyber Essentials certification first, then treating Cyber Essentials Plus as validation of controls already genuinely in place, a more reliable route than attempting Plus certification cold. Because the assessment is hands-on and device-specific, Cyber Essentials Plus also needs re-verifying annually alongside the underlying Cyber Essentials certification, since a control landscape confirmed sound a year ago provides no assurance about current patch status or configuration drift that may have accumulated since.
Cyber Essentials Plus 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.
