SaaSPlatform and integration Software as a Service
Software as a Service is a delivery model where the vendor builds, hosts, patches, and operates the application, and the customer accesses it through a browser, a thin client, or an API rather than installing and maintaining it on their own infrastructure, paying on a subscription or usage basis instead of buying a perpetual licence and running the software themselves. This shifts a meaningful set of responsibilities away from the customer: there is no server to patch, no database to back up, no infrastructure capacity to plan for, and version upgrades roll out to every customer on the vendor's release schedule rather than requiring an internal project to plan and test an upgrade. Microsoft 365 itself is the clearest example most IT teams work with daily, and the same model underlies most of the modern tooling layered on top of it, including cost optimisation, licence management, and tenant reporting products that connect to a customer's tenant through Graph and Azure APIs rather than being installed inside it. That distinction between SaaS and installed software matters practically when evaluating a vendor: a SaaS product's total cost of ownership includes the subscription price but not separate infrastructure, patching, or backup effort on the customer's side, whereas a Win32 desktop application, such as an application packaging tool that runs on an engineer's own machine against local and captured application data, keeps deployment and update control with the customer and avoids sending source application data to a third-party service, which is a deliberate trade-off some vendors make for exactly that reason rather than an oversight. Because a SaaS provider holds customer data and, for products acting against a Microsoft tenant, often holds standing API access to that tenant, the questions worth asking before adopting any SaaS tool in a Microsoft 365 or Azure estate go beyond price and features: where is data hosted and processed, does the vendor's terms confirm customer data is not used to train models, what certifications does the vendor hold such as ISO 27001 or Cyber Essentials, how is multi-tenant access isolated so one customer's data cannot leak into another's view, and what happens to data on contract termination. For MSPs specifically, SaaS multi-tenancy is also an operational advantage rather than only a risk to manage, since a properly built multi-tenant SaaS platform lets a partner apply the same cost, security, and reporting workflow consistently across every managed customer from one login, rather than each customer needing separately hosted and separately maintained instances, which is the scaling problem SaaS was built to solve in the first place.
SaaS 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.
Azure savings plan
An Azure savings plan for compute is a commitment discount that works differently from a reservation: instead of committing to a specific virtual machine size and region, the customer commits to a fixed amount of spend per hour for a one-year or three-year term, and each hour Azure automatically applies that benefit to whichever eligible compute usage carries the highest discount first, with anything above the hourly commitment billed at standard pay-as-you-go rates. The eligible service list is broad and applies automatically across regions and families without the customer having to predict where a workload will run, covering virtual machines, App Service, Container Instances, Container Apps, the Functions premium plan, dedicated hosts, and Azure Spring Apps for Enterprise. This flexibility is the direct trade-off against a reservation: a savings plan gives up some of the deepest possible discount depth in exchange for a benefit that follows the spend rather than waiting for one specific resource configuration to keep running, which makes it a better fit for workloads that shift between VM families, move across regions, or are still evolving in shape. Two mechanics matter when sizing a savings plan. The hourly benefit is use-it-or-lose-it: any hour where actual eligible usage runs below the committed amount leaves that portion of the commitment unrecovered, it does not roll forward into a later hour, so committing too aggressively wastes money just as surely as not committing at all. And a savings plan cannot be cancelled, exchanged, or refunded once purchased, unlike a reservation, which makes accurate sizing more consequential; the recommended approach is to size the hourly commitment against a genuine look-back on real usage data, typically from Azure Advisor or Cost Management recommendations, rather than a forecast or a round number. In a mixed estate the two commitment types are usually combined rather than treated as an either-or choice: reservations cover the stable core that will not move for the length of the term, and a savings plan absorbs the remaining variable layer that a reservation cannot commit to safely.
Savings Plan 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.
Microsoft Secure Score
Microsoft Secure Score is a measurement and benchmarking tool within the Microsoft 365 Defender portal that converts an organisation's security configuration across identity, devices, applications, and data into a single numeric score, alongside a prioritised list of specific improvement actions, each carrying a defined point value based on Microsoft's assessment of its security impact and, for many actions, its implementation effort. The score itself is intentionally comparative rather than absolute: it is presented as a percentage of the maximum achievable score for the organisation's specific licensed products, alongside a benchmark against similar organisations by size and industry, which is meant to answer 'how does our posture compare to peers' rather than 'are we secure,' a distinction worth being precise about, since a high percentage score reflects how many of Microsoft's recommended configurations have been implemented, not an independent, holistic assessment of actual resilience against the specific threats an organisation faces. Each improvement action links directly to where it can be configured, and many, particularly around Conditional Access baselines, Defender policy settings, and Entra ID configuration, can be implemented or partially automated directly from within the Secure Score interface itself, which makes it a genuinely useful starting checklist for organisations early in a security maturity journey, giving a concrete, ranked list of next steps rather than an open-ended 'improve security' mandate with no clear starting point. The score's most significant practical limitation is that it can be gamed, deliberately or not, by implementing recommended controls that do not actually fit the organisation's environment purely to gain points, for example enabling a restrictive Conditional Access policy that technically satisfies a scored recommendation but was never properly tested against real sign-in patterns, or completing actions that only apply to features the organisation does not meaningfully use, and a security team optimising primarily for the numeric score rather than for actual risk reduction can end up with a high Secure Score and a materially unchanged, or even worse, real-world security posture. Trend tracking over time is where the tool earns most of its ongoing value, since a consistently rising score, tracked against a defined target, gives a concrete, auditable basis for internal security reporting to leadership or a board, translating what would otherwise be a qualitative 'we've been working on security' statement into a specific, trackable metric, and it is increasingly referenced directly in cyber insurance underwriting conversations and vendor security questionnaires as one data point, alongside more specific controls like MFA coverage and patch cadence, in demonstrating an organisation's overall security investment and trajectory rather than functioning as a certification or compliance attestation in its own right.
Secure Score 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.
Microsoft Purview sensitivity labels
Microsoft Purview sensitivity labels are the mechanism for classifying and protecting content, documents, emails, Teams meetings, and, in the current unified taxonomy, containers such as SharePoint sites, Teams, and Microsoft 365 Groups, based on its business sensitivity, applying protections that travel with the content itself rather than depending solely on where it happens to be stored. A label such as Confidential or Highly Confidential can carry encryption that restricts who can open, edit, forward, or print a document, visual markings like headers, footers, or watermarks that make the classification visible to users, and content-specific restrictions, and because the protection is embedded in the file through Microsoft's rights management service, it persists even if the file is later downloaded, emailed, or moved outside the tenant, unlike protections that rely purely on the storage location's own permissions. Labels can be applied manually by end users choosing from a defined taxonomy, recommended to users based on content detected as matching a sensitive information type, or applied automatically for content matching defined patterns, and container-level labels can independently drive settings like whether a Team or SharePoint site permits external sharing or unmanaged device access, meaning a single label choice made when a site is created can carry meaningful and sometimes overlooked security consequences. Sensitivity labels are commonly confused with retention labels despite sharing the same Purview infrastructure and admin experience: sensitivity labels control who can access and what they can do with content, while retention labels control how long content is kept and whether it is disposed of, and while both can, since Microsoft's taxonomy unification, be managed from a similar interface, they answer entirely different governance questions and a given piece of content will often carry one of each rather than only one or the other. Getting real value from sensitivity labels depends heavily on classification accuracy, since a taxonomy with too many overlapping labels leads to inconsistent application and user confusion about which one to choose, while automatic classification tuned too broadly generates false positives that erode user trust in the labelling prompts and encourage them to be dismissed rather than acted on; a commonly recommended approach is starting with a small number of clearly differentiated labels and expanding only where a genuine business need for finer granularity is demonstrated. For organisations pursuing ISO/IEC 27001 or SOC 2, sensitivity labels are frequently the practical implementation of the standard's required information classification scheme and the access control and data handling controls that follow from it, and DLP policies commonly reference sensitivity labels directly as a condition, meaning a document's label can be the trigger that blocks it from being shared externally or attached to an outbound email in the first place.
Sensitivity labels 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.
Azure Virtual Desktop session host
An Azure Virtual Desktop session host is a virtual machine, running in an organisation's own Azure subscription, that has the Azure Virtual Desktop agent installed and is registered into a host pool, making it available to run remote desktop or published application sessions for end users; it is the actual compute resource being consumed, in contrast to Windows 365, where the underlying compute is abstracted away from the organisation entirely inside a fixed-fee Cloud PC. Session hosts come in two operating system modes with materially different economics and use cases: single-session hosts, where one Windows machine serves exactly one concurrently connected user, similar in shape to a traditional VDI desktop, and multi-session hosts, using the Windows 11 (or 10) Enterprise multi-session edition that only Azure Virtual Desktop is licensed to run, where many users share sessions on the same underlying virtual machine simultaneously, which is the configuration that gives Azure Virtual Desktop its cost advantage over both traditional VDI and Windows 365 at scale, since compute cost is shared across many concurrent sessions rather than dedicated one-to-one per user. Session hosts are organised into host pools, which group hosts with an identical configuration and image together and apply a load-balancing algorithm, either breadth-first, spreading new sessions evenly across all available hosts to maximise per-user performance, or depth-first, filling one host to its configured maximum session limit before moving to the next, which is typically chosen to allow autoscaling to deallocate and stop unused hosts entirely and stop paying for their compute during low-usage periods. That autoscaling behaviour is where Azure Virtual Desktop's cost model diverges most sharply from Windows 365's fixed monthly fee: because session hosts are ordinary Azure virtual machines billed by the hour, organisations that configure scaling plans correctly, powering hosts down outside business hours and scaling host count to match actual concurrent demand through the day, can achieve substantially lower effective per-user cost than a fixed-fee Cloud PC model, but only if the scaling plan is actually tuned to real usage patterns; a host pool left running at a fixed size around the clock loses that advantage entirely and can end up more expensive than the Windows 365 equivalent for the same user population. Session host maintenance is an ongoing administrative responsibility that Windows 365 largely abstracts away from the organisation: patching, image updates, agent updates, and monitoring host health for issues like FSLogix profile container failures or capacity exhaustion all fall to whoever administers the host pool, which is the direct trade-off for the deeper cost and configuration control Azure Virtual Desktop offers over the simpler, more managed Windows 365 model.
Session host 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.
SharePoint Online
SharePoint Online is Microsoft's cloud-based collaboration and document management platform, delivered as part of Microsoft 365, providing team sites, document libraries with version history and co-authoring, list-based data storage, and an intranet and portal-building capability through modern SharePoint pages and hub sites, and it functions as the storage and content-management layer underneath several other Microsoft 365 services rather than only as a standalone destination users deliberately navigate to. Every Microsoft Teams team has a connected SharePoint site backing its Files tab, every Microsoft 365 group that gets created, whether directly or through Teams or Planner, provisions a SharePoint site alongside it, and OneDrive for Business itself runs on the same underlying SharePoint storage infrastructure as a personal site per user, which means SharePoint governance decisions, site creation policies, storage quotas, external sharing defaults, ripple directly into Teams and OneDrive behaviour even for administrators who think of those as separate services. Site sprawl is the most common long-term SharePoint governance issue in mature tenants, arising from the same root cause as Teams sprawl: because a SharePoint site is provisioned automatically every time a Microsoft 365 group, Team, or Yammer community is created, and because there is no default automatic cleanup, organisations accumulate large numbers of sites tied to finished projects, disbanded teams, or one-off initiatives, each one still consuming storage against the tenant's pooled quota and still representing a permissions surface that needs reviewing in any access audit. External sharing is configured at both the tenant level, in the SharePoint admin center, and per-site, and the interaction between these two layers is a frequent source of confusion: a restrictive tenant-wide default does not retroactively lock down a site that was configured more permissively before the policy changed, and a permissive tenant default allows any individual site owner to share as broadly as "anyone with the link" unless a site-level restriction overrides it, so a genuine external sharing audit has to check both levels rather than assuming the tenant setting tells the whole story. Retention and compliance features, including retention labels, sensitivity labels from Microsoft Purview, and legal hold, apply at the SharePoint site and document level and are frequently the actual mechanism enforcing a broader Microsoft 365 compliance policy that appears, from a policy summary, to be a single organisation-wide rule but is technically implemented as potentially many separate site-level configurations that each need to be correctly applied and periodically verified. Storage itself is pooled across the tenant rather than fixed per site, calculated from a baseline plus a per-licensed-user increment, which means unexpectedly high SharePoint storage consumption is usually diagnosable back to a small number of specific large sites or document libraries rather than being an evenly distributed problem across the estate.
SharePoint 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.
Unused software entitlement
Shelfware is paid software, most commonly a Microsoft 365 or Azure-adjacent subscription licence, that sits assigned or purchased but genuinely unused: seats bought for a headcount projection that did not materialise, licences assigned to a project team that has since disbanded, premium tiers bought organisation-wide when only a subset of users needed the extra capability, or entitlements left in place after the person or workload they supported has gone. The term originated in enterprise software procurement to describe a licence bought and left, metaphorically, on a shelf, and it has become one of the most consistently underestimated categories of waste in a Microsoft estate because it is invisible on a normal admin console view: a licence that is assigned looks identical to one that is being used until someone cross-references assignment against actual activity. Shelfware differs from the closely related idea of a simply unassigned licence, which is a seat purchased but never allocated to any user at all; shelfware specifically describes the harder-to-spot case where a licence is assigned to a real account, so it looks legitimately in use on a licence report, while the underlying account is dormant, has left the organisation, or never needed that tier of subscription in the first place. Finding it requires comparing three figures that are rarely reviewed together: what was purchased, what is assigned, and what is genuinely active, using last sign-in data, per-service usage reports, and role or plan-mix context rather than assignment counts alone. Shelfware accumulates quietly rather than appearing in one dramatic event, through joiner-mover-leaver gaps, over-provisioned plan tiers bought for simplicity rather than fit, and departmental subscriptions nobody owns after a reorganisation, which means the fix is rarely a single cleanup. A monthly or quarterly reclaim review, treating licence reclaim as a repeatable operating habit rather than an occasional audit, is the only way that keeps the gap from reopening as the estate continues to change.
Shelfware 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.
Sideloading
Sideloading is installing an MSIX application onto managed Windows devices directly from a trusted internal source, such as Microsoft Intune or a self-hosted App Installer update feed, rather than through the public Microsoft Store, using a code-signing certificate the target estate already trusts to establish the package's identity and authenticity in place of store curation. This matters because MSIX enforces package identity and signature validation as a core part of the format, not as an optional security add-on: a device will not install an MSIX package at all unless it either comes through the Store or the signing certificate used to sign the package is explicitly trusted by that device, most commonly because the estate has deployed the organisation's own root or intermediate certificate to its managed devices through Intune configuration policy. Sideloading is the standard, expected distribution path for two overlapping categories of application: internal line-of-business software that will never be published to a public store because it is specific to one organisation, and independent software vendor, or ISV, applications an enterprise customer needs distributed and updated under its own management control rather than through a public listing. For applications that need to stay current without manual reinstallation, an App Installer update feed lets a sideloaded MSIX package check a defined URL for newer versions and update itself automatically on a schedule the estate controls, functioning as a lightweight, self-hosted equivalent to the update mechanism the public Store provides for listed apps, without surrendering distribution control to a public marketplace. The signing certificate is the actual trust anchor underpinning the entire sideloading model, so certificate lifecycle management, expiry monitoring, secure private key storage, and a controlled process for who is authorised to sign a package before it ships, is a genuine operational discipline in its own right, not an incidental detail; a certificate that unexpectedly expires or is compromised can block every sideloaded application across an estate simultaneously, or, worse, open a route for an untrusted package to appear trusted, which is why signing pipeline security deserves the same governance attention as the packaging process itself.
Sideloading 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.
SKUCommercial and channel Stock Keeping Unit
SKU, Stock Keeping Unit, is the specific product or subscription plan identifier used throughout Microsoft's licensing systems, Microsoft 365 admin center, Entra ID, and the Microsoft Graph API among them, to distinguish one purchasable offering from another, Microsoft 365 E3 from E5, Business Standard from Business Premium, an Enterprise Mobility + Security add-on from the base plan it augments, and it is the unit that licence assignment, billing, and usage reporting are actually built around at a technical level. Each SKU bundles a defined set of service plans, the individual capabilities like Exchange Online, Teams, or SharePoint that together make up what a plan actually delivers, and understanding that a SKU is a bundle rather than an atomic unit matters in practice because two different SKUs can overlap substantially in the service plans they include, which is exactly how organisations end up with licence duplication, a user assigned both a standalone Teams licence and a Microsoft 365 SKU that already includes Teams, without anyone having deliberately decided to pay for the same capability twice. Microsoft's SKU catalogue has grown large and, in places, genuinely confusing over time, with historical naming inconsistencies, such as SKUs whose display name and underlying string identifier used in PowerShell or Graph queries do not obviously match, and near-identical-sounding plans that differ in subtle but licensing-relevant ways, which makes working directly from SKU identifiers rather than marketing names the more reliable approach for any script or tool doing licence analysis at scale. This SKU-level granularity is precisely where licence reclaim and cost optimisation work happens in practice: identifying which specific SKU a specific inactive user still holds, recognising when a user's actual usage pattern, judged by which service plans within their assigned SKU they demonstrably use, would be fully covered by a lower-cost SKU, and spotting SKU-level duplication across a tenant are all queries that operate at the SKU and service-plan level rather than at the coarser subscription or product-family level a billing invoice typically presents, which is why tooling built for licence optimisation needs to work with SKU and service plan data directly through Graph or PowerShell rather than relying on the admin center's summary views alone to catch waste that only becomes visible once you are looking at what is actually assigned and actually used at that level of detail.
SKU 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.
System and Organization Controls 2
SOC 2 (System and Organization Controls 2) is a widely used US-originated attestation framework, developed by the American Institute of Certified Public Accountants (AICPA), under which an independent auditor evaluates and reports on a service organisation's controls relevant to one or more of five defined Trust Services Criteria: security (mandatory in every SOC 2 report and often called the common criteria), availability, processing integrity, confidentiality, and privacy, with the organisation itself selecting which of the latter four criteria beyond security are actually relevant and in scope for its report. Unlike a certification such as ISO/IEC 27001, SOC 2 does not result in a certificate; it results in an attestation report written by the auditing CPA firm, and it comes in two distinct types that are frequently confused: a Type I report assesses whether the described controls are suitably designed at a single point in time, while a Type II report, generally considered materially stronger and what most enterprise customers actually expect, assesses whether those controls operated effectively over an observation period, typically six to twelve months, based on evidence sampled throughout that window rather than a single snapshot. SOC 2 reports are also not public documents in the way a certification badge is; they are shared under NDA directly with customers and prospects who need assurance, usually via a dedicated portal like a trust centre, which means SOC 2 status functions primarily as a sales and procurement enablement tool for organisations selling software or services to other businesses, particularly in the US market and increasingly in UK enterprise SaaS procurement, rather than a broad public trust signal in the way a website badge might imply. For a UK-based Microsoft 365 or Azure-focused vendor or MSP, SOC 2 most commonly arises when selling into US-headquartered customers or customers with US-influenced vendor risk processes, where it is often requested alongside or instead of ISO/IEC 27001, and organisations pursuing both frequently find substantial control overlap, since both frameworks expect similar underlying practices around access control, change management, monitoring, and incident response, even though SOC 2's criteria structure and reporting format differ meaningfully from ISO's clause-and-Annex-A structure. A common evaluation mistake is treating any SOC 2 report as equivalent assurance regardless of type or scope: a Type I report, a report covering only the security criterion with no availability or confidentiality commitments, or a report with a heavily carved-out or narrowly defined system description all represent materially less assurance than a Type II report with a broad scope and a clean opinion, so reviewing the actual report, including its scope, the auditor's opinion, and any noted exceptions, rather than relying on the vendor's claim of having "a SOC 2", is standard due diligence practice before relying on it.
SOC 2 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.
Single Sign-On
Single Sign-On lets a user authenticate once against a central identity provider and then access multiple separate applications without being prompted to sign in again for each one, which is the mechanism that makes a large application estate practically usable, since without it every application effectively holds its own password, and both password fatigue and the resulting helpdesk cost of password resets scale directly with the number of separate credentials a user has to manage. In the Microsoft ecosystem, Entra ID acts as the identity provider for SSO using standard federation protocols, principally SAML and OpenID Connect with OAuth 2.0, with WS-Federation still present for some legacy line-of-business applications, and thousands of pre-integrated applications are available through the Entra ID application gallery with SSO configuration largely templated rather than built from scratch; applications outside the gallery can still be integrated manually as long as they support one of the standard protocols. Provisioning is a closely related but distinct capability, usually delivered through SCIM, which automatically creates, updates, and disables user accounts inside the target application as they change in Entra ID, so that SSO handles authentication while SCIM handles the account lifecycle behind it, and deploying SSO without also wiring up provisioning is a common gap that leaves accounts in target applications not actually synchronised with their source of truth, meaning a disabled Entra ID account can still leave an active, orphaned account sitting in a downstream application. For hybrid environments still running on-premises Active Directory, Seamless SSO uses Kerberos against the on-premises domain to let domain-joined devices sign in without any prompt at all on the corporate network, while password-based SSO offers a lighter-weight option for older applications that only support form-based login, storing and autofilling credentials through the browser extension rather than true federated authentication. The security trade-off inherent to SSO is worth being explicit about: centralising authentication into one identity provider is what makes broad access manageable, but it also means that single identity provider account becomes a genuinely high-value target, since compromising it can cascade into every connected application at once rather than just one, which is exactly why SSO is deployed in practice alongside Multifactor Authentication and Conditional Access rather than as a standalone convenience feature, and why session lifetime and reauthentication frequency settings for sensitive applications need deliberate configuration rather than being left at defaults that favour convenience over risk.
SSO 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.
