Skip to content
Labs
Sign inRequest a demo

QUME (QuantineliQ Unified Managed Engine)

Manage and secure every laptop, phone and server from one auditable console

QUME replaces separate device management, patching, endpoint security, SIEM and network access control for Windows, macOS, Linux, Android and iOS. AI insights flag anomalies and draft the fix, every wipe needs a second approver, and every patch is confirmed on the device. Post-quantum encrypted from day one.

For CISOs and IT infrastructure leads

Book an architecture briefingSign in to QUME

Today: a product for each job

  • Device managementMDM and UEM
  • Patch and vulnerabilityscanners and patch tools
  • Endpoint securityhardening and device control
  • Detection and SIEMlog collection and correlation
  • Network access controlRADIUS and 802.1X

QUMEOne console

  • Device management
  • Patch and vulnerability
  • Endpoint security
  • Detection and SIEM
  • Network access control

One agent, one policy, one audit trail

Device management, Patch and vulnerability, Endpoint security, Detection and SIEM, Network access control, each a separate product with its own console today, all handled in QUME: One agent, one policy, one audit trail.
5platformsAndroid, Windows, macOS, iOS, Linux
1console in place of five toolsMDM, patching, endpoint security, SIEM and NAC
2people for every wipeTwo-person approval, enforced on the server
100%post-quantum connectionsHybrid key exchange on every QUME connection

What it is

One platform for every endpoint you own

QUME is a unified endpoint management platform that was built post-quantum from the first handshake: hybrid key exchange on every connection, post-quantum signatures on every instruction, and a tamper-evident record of what was done to each device. It deploys as multi-tenant cloud, on premises, or entirely air-gapped from the same images.

Why quantum-safe nowHow onboarding works

QUME AI

AI that finds the anomaly and drafts the fix

QUME’s AI reads the events from every device it manages. It flags anomalies, predicts what is about to go wrong, recommends changes and drafts remediations and policies, and an assistant explains any policy decision from its trace. Each draft waits for a person’s review before it acts.

QuantineliQ AIDetection and SIEM

QUMEAI insights

Sample data

  • AnomalySign-ins at night from a new network on three finance laptops03:12

    14 sign-ins between 02:10 and 03:40 on ws-fin-114, ws-fin-118 and lt-fin-031, from a network none of them has used before. Mapped to MITRE ATT&CK T1110, brute force.

    Drafted Require step-up sign-in for the finance group and open an investigation with the three devices attached.

    Waits for review by a person before it acts

  • Prediction38 laptops will miss Tuesday’s patch window09:40

    At their current check-in pattern, 38 laptops in the sales ring will not be online before the window closes at 18:00 on Tuesday.

    Drafted Move them to Wednesday’s ring and tell their owners, with the patch cached at their branch.

    Waits for review by a person before it acts

  • RecommendationTurn off SMBv1 on 112 Windows servers10:05

    SMBv1 is still enabled on 112 servers, and no client has used it in the last 30 days.

    Drafted A drafted policy turns it off in three rings, with a rollback if a server reports a failure.

    Waits for review by a person before it acts

  • Drafted remediationIsolate srv-web-04 from the database network10:22

    Web shell indicators on srv-web-04 (MITRE ATT&CK T1505.003), with outbound connections to an address seen nowhere else on the estate.

    Drafted A drafted playbook isolates the server inside its blast-radius budget and keeps the console session for the investigator.

    Waits for review by a person before it acts

Quantum-safe

Ready for quantum risk today, without a migration project

Data captured today can be decrypted once a large quantum computer exists. QUME’s connections already use hybrid post-quantum key exchange and its instructions carry post-quantum signatures, so there is nothing to migrate later.

Check your exposureQuantum-safe in QUME
Why quantum-safe, in three picturesA Bloch sphere whose state vector precesses: a qubit is a point on that sphere rather than a bit that is secretly zero or one. Beside it, an interference pattern in which amplitudes for wrong answers cancel and one peak survives, the step Shor’s algorithm uses to recover an RSA or elliptic-curve private key. Below, a point lattice with its shortest vector marked: the problem ML-KEM and ML-DSA are built on.superpositioninterferencelattice hardness — ML-KEM · ML-DSA

Device management · MDM and UEM

MDM and UEM for every endpoint, on five platforms

Android, Windows, macOS, iOS and Linux enrol into the same record, carry the same identity and move through the same states. The differences between platforms live in the agent, not in the operator’s head.

More on device management
A device proves what it is before it is issued a certificate, and what it proved sets its trust tierFour linked stages run left to right: a hardware root, a single-use server nonce, the binding of the certificate request to the attested key, and the issued certificate. A connector runs from the certificate down to the first of three trust tiers, attested, software key and unproven, and only the attested tier is highlighted.hardware rootTPM · StrongBoxserver noncesingle-usekey bindingbound to CSRcertificateissuedattestedsoftware keyproved neither
  1. The device presents hardware-backed attestation: Android Key Attestation, Windows TPM 2.0, Apple App Attest.
  2. The server supplies the nonce and the certificate request is bound to the attested key, so a captured enrolment token cannot enrol a second machine.
  3. What the device could prove decides its trust tier, and every dangerous command checks the tier rather than flattening the fleet into “enrolled”.

Policy and compliance

Know every device is compliant, control by control

A policy is not a document that describes an intention. It is compiled into a bundle, signed, delivered as desired state, applied by the agent and read back control by control, so the console shows what the device is, not what it was told.

More on policy and compliance
One policy compiles to a bundle per cohort, and a cohort serves many devicesA single policy on the left feeds a compiler. The compiler fans out to six cohort bundles stacked vertically, and each bundle feeds a row of device dots on the right, so the work is proportional to the number of cohorts rather than to the number of devices.policyeffectivecompile+ signcohort 1cohort 2cohort 3cohort 4cohort 5cohort 6
  1. A policy is compiled once, not once per device.
  2. It becomes one signed bundle per cohort: the devices whose effective policy resolves the same way.
  3. Every device in a cohort takes that same bundle and reads its controls back, so the estate size does not change the work.

Patch and vulnerability

Patch management that proves the fix landed

A finding does not close because a command succeeded. The installer can roll back, the reboot can be declined, the vulnerable file can still be on disk beside the new one. QUME closes a finding only on evidence from the device.

More on patch and vulnerability
A ring gate: three conditions, all of which must hold before the next ring startsFour rings of increasing size run left to right, with a gate between the first two. The gate lists three conditions, enough devices reported, the soak elapsed and the failure rate under the threshold, and opens only when all three hold. The controls set the reported failures and the other two conditions.canaryring 2ring 3ring 4the gate after the canaryenough devices have reported (20)the soak period has elapsedfailures are under 5% (0%)OPENnext ring starts

Gate OPEN All three conditions hold, so the next ring may start.

  1. A wave installs across the estate in rings, a small canary first and then larger groups, with a gate between each pair.
  2. A gate has three conditions and all must hold: enough devices have reported, the soak has elapsed, and the failure rate among those reports is under the threshold.
  3. A device that never answered is unreachable, not failed. It blocks the gate rather than halting the wave or letting it complete against devices that never received it.

Detection and SIEM

A SIEM and threat detection built into your endpoint console

Collect, detect, hunt and respond without a separate product, with AI insights that flag anomalies and draft the fix for a person to review. Events land durably before they are parsed, and playbooks act through the same controls an operator would use, under budgets.

More on detection and SIEM
From raw event to contained device, through a playbook with a budgetFive stages run left to right: sources, a landing zone that keeps raw bytes, parsing, detection, and a playbook. Under the playbook two outcomes are shown: the device is isolated within budget, or the run waits for approval.sourcesendpoints · serverslanding zoneraw bytes keptparsegaps counteddetectrules · ATT&CKplaybookwithin budgetdevice isolatedwaits for approvalover budget: refused
  1. Raw events land in object storage first, so a parser improved next quarter can be re-run against what actually arrived.
  2. Events that do not map are counted as a gap rather than dropped, so a source that stops making sense shows up early.
  3. Playbooks act through QUME’s own controls, under a blast-radius budget, and a run that needs approval waits instead of half-executing.

Network access

Network access control (NAC) without another product

RADIUS and TACACS+ built into QUME, with the admission decision served from a replica so an authentication never waits on a database query.

More on network access
A device joins the network: certificate, RADIUS, posture, then a networkFour stages run left to right: the device presents its QUME certificate, RADIUS checks it with Message-Authenticator required, the posture verdict is read, and a network is assigned. Below, three outcomes: full access, a restricted network, or refusal.device certificateissued by QUMERADIUS · 802.1XMessage-Auth requiredposture verdicttier · compliancenetwork assignedVLAN by policyfull accessrestricted networkrefused
  1. The device authenticates with the certificate QUME issued at enrolment; Message-Authenticator is required on every RADIUS exchange.
  2. Compliance verdict, trust tier and presence decide the network the device gets.
  3. When posture changes, Change of Authorization moves or disconnects the live session.

Remote support

Remote sessions nobody can run quietly

No managed endpoint opens an inbound port. Both sides dial out to a broker, the user is told who is watching in the words they agreed to, and the session does not run unrecorded.

More on remote support
A remote session: asked for, agreed on the device, recorded and sealedFive stages run left to right: an operator asks for a session with a reason, the device asks its user, the session runs with the operator named on screen, it is recorded to write-once storage, and the recording is sealed when it ends.requestwith a reasonconsenton the devicesessionoperator namedrecordedwrite-oncesealedhash-chained
  1. The operator asks for a session and says why; the dangerous capabilities need a second person.
  2. Only the device reports the user’s answer, and silence declines.
  3. The session is recorded to write-once storage and sealed when it ends.

Identity

Federated identity, real segregation of duty

One compromised admin cannot wipe your fleet. Sign-in federates to your organisation’s identity provider, authority inside QUME is a capability matrix checked on every call, and the dangerous half of it needs two people.

More on identity
One decision point: every request evaluated once, returning a decision id and reason codesEight gates stacked in evaluation order, from the credential check at the top to the quantum requirement at the bottom, ending in a single allow-or-deny outcome. Choosing a request marks each gate as passed, refused or never reached, and reports the reason code the decision carries.a credential was presentedthe role grants the actionthe step-up is fresh for the classthe admin workstation is complianta binding reaches this resourcethe target device’s posturesession risk is under the ceilingthe quantum requirement is reachableDENY — ROLE_LACKS_CAPABILITYdecisionId dec_…
Try a request

DENY — ROLE_LACKS_CAPABILITY The roles on the session do not grant the action. It is the cheapest check that can refuse, so it runs before anything that would need a network call. The decision carries an id of its own, which the audit record quotes and a support engineer asks for.

  1. Every request at every enforcement point is evaluated once, by one decision point, over principal, action, target, organisation, posture and risk.
  2. The gates run cheapest first, so a request that was never going to be allowed does not make three network calls to find out.
  3. It never returns an error. A plane it cannot reach is a deny, an allow may be cached for thirty seconds, and a deny never is.

Evidence and audit

Tamper-proof audit trail your auditor can verify offline

Audit is hash-chained, anchored with a post-quantum signature and verifiable offline. The archive is immutable by object lock, and QUME says so plainly when that immutability is what prevents an erasure.

More on evidence and audit
A tamper-evident audit chain: an altered entry breaks the chain at a known pointFive audit entries in a row, each linked to the one before it by the previous entry’s hash. The middle entry is marked as altered, and the link leaving it is drawn as broken, with the break marked at exactly that point rather than anywhere along the row.entry 1h(n−1)entry 2h(n−1)entry 3alteredentry 4h(n−1)entry 5h(n−1)break detected here
  1. Every entry carries the hash of the entry before it, so the record is a chain and not a list.
  2. Anchors are signed with ML-DSA-65 and published; a standalone verifier checks an export against the public key alone, with no access to the running system.
  3. An altered entry does not fail quietly. The chain breaks at that entry, and the break is located rather than suspected.

And everything around it

Endpoint security and day-to-day operations

Endpoint securityHardening, device control, encryption keys and firmware credentialsOperationsReports, an assistant over your own data, self-service and licensingDeploymentCloud, on premises or air-gapped from the same imagesEvidence and auditHash-chained records, verifiable offline

Deployment

Cloud, on-premises or air-gapped endpoint management, from the same build

The difference between a cloud tenant and an air-gapped installation is a values file, not a different codebase. Kubernetes, Docker Compose and native binaries are all first-class targets.

More on deployment
An air-gapped installation: a signed bundle goes in, and nothing goes outA boundary encloses the installation and its own internal post-quantum certificate authority. A signed offline bundle enters through a fail-closed updater on the left. Three outbound arrows leave the boundary on the right and each one is crossed out: there is no egress at any point.signed bundleofflineno egress at any pointservicesPQC CAinternalfail-closed updaterblocked
  1. The same images run in the cloud, on premises and air-gapped; the difference between them is configuration, not a separate product.
  2. An internal post-quantum certificate authority issues every certificate inside the boundary, so nothing needs to reach a public one.
  3. Updates arrive as a signed offline bundle, and the updater fails closed when it cannot verify one.

  • Cloud

    Multi-tenant and cell-based. Organisations shard across cells, and each cell is a full cluster with its own database, bus and gateways.

  • On premises

    The same images and the same Helm chart for one organisation, on Kubernetes, Docker Compose or native binaries.

  • Air-gapped

    No egress at any point: an internal post-quantum CA, a signed offline bundle and a fail-closed updater.

Getting started

From an empty install to a managed device

Three steps. The first runs on the host, because the first organisation needs an administrator before there is anyone to issue a token.

  1. Create the organisation

    qume-onboard tenant create writes the organisation (name, cell, residency and retention) and qume-onboard admin grant creates its first administrator.

  2. Connect your identity provider

    Point QUME at your OIDC or SAML provider and map a claim to a QUME role. Joiners, movers and leavers are handled where they already are.

  3. Enrol the first device

    Create a single-use enrolment token, install the agent and let it attest. The device appears at its trust tier and takes its first policy on the next check-in.

See QUME on your own devices

We will enrol a few of your devices and walk through policy, patching, detection and the AI insights with your team.

Book an architecture briefingHow licensing works