Skip to content

How software licence management benefits IT security

The inventory you build to survive an audit is the same inventory your security team has been asking for. Unsupported versions, unpatched installs, unauthorised software and forgotten access are licensing problems and security problems at the same time.

Most people meet software asset management through cost and compliance. You buy a tool because an audit went badly, or because renewals keep arriving with numbers nobody can explain.

The security benefit tends to be discovered afterwards, by accident, when somebody in security asks a question and finds the answer already exists. That is not a coincidence. The work SAM requires — knowing what is installed, on what, in what version, used by whom — is the same work vulnerability management requires. One programme, two sets of consumers.

What the inventory tells security

A complete software inventory lets your security team identify and act on software that is:

  • Past the publisher’s end of support. No patches are coming. The vulnerability that appears next month will not be fixed.
  • Current but behind. Supported, patchable, and not patched.
  • Unauthorised. Installed outside any approval process, which means outside your patching, your vetting and, usually, your knowledge.
  • Redundant. Still installed, no longer needed by anyone, still exposing whatever it exposes.
  • Legacy. Retained because one process depends on it, and rarely reviewed on the grounds that it has always been there.

Every one of those is also a licensing question. That is the point of the argument: you are not building two inventories, you are building one and pointing it at two problems.

Recognition is what makes the inventory usable. Raw inventory data is a mess of install strings, and the same product appears under a dozen different names depending on how it was packaged. CerteroX SAM resolves what it finds against the Software Recognition Database — over 3.5 million titles, normalised by publisher, product and version — so “what is installed” produces a real answer rather than a list requiring interpretation.

On top of that sits the lifecycle data. Recognised titles carry release date, end of support and extended support dates, which is what turns “we run version 12” into “version 12 left support in March and there is no extended support option”. Without those dates, an inventory tells you what you have but not what to worry about, and the list is too long to triage by hand.

Keeping software current

Old and redundant software is the easy case. Find it, confirm nobody depends on it, remove it.

Software that is still in use is harder, and splits into two distinct problems.

An outdated version is still deployed and needs replacing. Dynamic groups built from a query — or from SQL where the query builder is not expressive enough — target every machine running the version in question, and keep targeting them as new ones appear. Software distribution then handles the removal and the replacement across MSI, EXE and Click-to-Run packages, with a comparable path through the SCCM interface where SCCM is your deployment mechanism. Windows 11 upgrade orchestration exists for the specific case of moving a whole fleet of machines onto a supported operating system.

To be clear about what is automated and what is not: you define the target, you supply the package, you set the policy. What disappears is a technician touching each machine and the drift that follows when they miss forty of them. The decision stays with IT, which is where it belongs.

The current version is deployed but unpatched. Patch management runs against WSUS-registered computers, with policies defining the criteria under which an update is applied, downstream server support for distributed sites, and synchronisation from an upstream server on a schedule. The result is that patch state stops being a separate report someone compiles monthly and becomes an attribute of the machine, sitting next to what is installed on it and who uses it.

Prevention, not just detection

Finding unauthorised software after it is installed is useful. Preventing it is better.

Application use and prohibition rules let you name software that is not permitted and block it rather than merely report it. Governance Policies take that further — compliance expressed as rules and evaluated continuously, so you are asserting a required state rather than reviewing a report. The policies that ship as examples are security policies: BitLocker enabled, Defender running, Azure VM tag hygiene. Policy definitions export and import as JSON, so a control you agree once is a control you can move between environments and put under version control rather than re-key.

Usage metering closes the loop from the other direction. File-based metering records first-used and last-used per title and produces a utilisation figure over a rolling 90-day window. Software nobody has opened in three months is a licence you can reclaim and an attack surface you can remove, and it is the same finding either way.

The argument extends further than it did in 2016

When this post was first written, “unauthorised software” meant an executable someone had installed on a laptop. That is no longer where the risk concentrates.

Today an employee grants a third-party application access to the company drive with two clicks, no download, no admin rights and no installer for anything to detect. The old inventory never sees it.

CerteroX SaaS Management addresses that directly, and the security value follows the same logic as before. Three converging discovery signals — identity provider sync from Entra ID and Okta, connector sync pulling authoritative user and licence lists from vendors, and a browser extension detecting SaaS domains with per-user attribution — surface what is genuinely in use, resolved against a catalogue of more than 35,000 applications. Forty-seven connectors ship today.

Three capabilities matter specifically to security:

OAuth grants are discovered and scored. Consented third-party applications are enumerated with a risk score from 0 to 100 built from data sensitivity, the scope granted, how consent was obtained and how long the grant has been dormant. Grants can be revoked in one click, or automatically as a workflow action. A forgotten integration with read access to your document store is a live exposure and, unlike an installed application, it survives the laptop being rebuilt.

Offboarding produces evidence. Most platforms tell you a user was offboarded. Here you see every licence they held, the connector status behind each revocation, whether it is pending, in progress or complete, and the monthly cost of anything still open. The leaver whose identity provider account was disabled on day one but whose seats in four other tools were not is both a spend problem and a standing credential.

Shadow AI is treated as its own category. AI tools are classified from application feature tags in the catalogue rather than a fixed list, so the detection set grows as the market does, and adoption is ranked by the share of the organisation using each tool. Ten people using an AI assistant is a different question from a thousand, and the risk assessment covers data sensitivity and GDPR, HIPAA and SOC 2 exposure.

The same principle applies to infrastructure. CerteroX Cloud Management surfaces inactive IAM users, unused console access and overly open security groups alongside the cost findings, because the cloud inventory that supports FinOps is the cloud inventory that supports security review. Again: one dataset, two consumers.

What to do with this

If you are building a business case for SAM, the security benefit is not a nice-to-have you mention at the end. In most organisations it is the argument that gets the programme funded, because the security team already knows it cannot answer “what is installed, where, and is it supported” and has usually given up asking.

Three questions worth putting to your current tooling:

  1. Can you list every install of a specific version across every platform you run — including the Macs, the Linux servers and the AIX frames — and produce it this afternoon rather than next week?
  2. For each of those titles, do you hold the end-of-support date, or are you looking it up per publisher when someone asks?
  3. Can you show what a departed employee still has access to, in SaaS as well as on the network, with the revocation status of each item?

If the answer to any of those is no, that is a security gap that a licensing programme would close as a by-product.

To see recognition, lifecycle dates, Governance Policies and OAuth grant risk scoring working together, book a demo.

Related reading

Other posts covering the same ground.

  • Top 10 IT Compliance Mistakes (And How to Avoid Them)

    The ten compliance failures that show up again and again in mature IT functions — manual tracking, hybrid blind spots, misread licence terms, unmanaged SaaS — and the controls that close each one.

    • ITAM
    • SAM
    • SaaS
    • Governance
    • Security
    8 min
  • Why SaaS is not the end of SAM

    SaaS removes the under-licensing risk, not the discipline. The question stops being "am I compliant?" and becomes "am I using what I pay for, and does the leaver still have access?"

    • SAM
    • SaaS
    • Governance
    7 min
  • 5 Ways Software Asset Management Improves Your Business

    SAM is usually sold as audit insurance. It is also a security control, a cost-reduction programme, due diligence for an acquisition, and the only reliable basis for rationalising your applications.

    • SAM
    • Governance
    • Security
    7 min
From reading to evidence

Put the hardest claim here
to a technical person.

Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.

No gated download at the end of it.