Scale the function, not the engineer.

The agent communicates outbound over TCP 443 to the cloud control plane. No inbound firewall rule, listening service, or VPN dependency is required on the endpoint, which means remote and roaming devices are managed identically to devices on the corporate network. Port 80 is used only to answer an initial request before redirecting to 443. One disclosure: where a third-party software vendor publishes update payloads only over anonymous FTP or HTTP, the agent may fall back to those protocols after repeated HTTPS attempts fail.

None is required for the management plane. There are no site servers, distribution points, or database instances for the customer to deploy, patch, or capacity-plan. Where agentless network devices are in scope, discovery and polling occur from within the customer network, so a host is required for that role only.

The API uses OAuth 2.0. Three scopes are available. Monitoring grants read-only access to monitoring data and organisation structure. Management permits creation and modification of organisations and devices and permits script execution on endpoints. Control permits remote access. Because Management scope can execute scripts, a credential holding it should be governed as a privileged credential and separated from read-only integrations. Client Credentials is the appropriate grant for server-to-server integrations, and applications should be restricted to it so an interactive flow cannot be used.

Encryption state is monitored rather than assumed. BitLocker status is evaluated as a condition covering enabled, disabled, locked and unlocked states, with exclusions available for boot, recovery and removable volumes; FileVault status is evaluated equivalently on macOS with a duration threshold. Because these are conditions rather than a point-in-time report, a device whose protection is disabled after deployment is surfaced as an alertable state rather than discovered at audit.

No. The platform addresses endpoint security posture — whether protection is present, enabled, current, and whether more than one antivirus product is installed and competing — and it performs the remediation and patching that follows a finding. It is not a replacement for a dedicated EDR or EPP product, and it is designed to operate alongside one rather than instead of it.

Data location is determined by the instance the tenant is provisioned into, and backup storage in particular uses region-specific endpoints. Because this carries contractual and regulatory consequence, the current instance and data-handling documentation for the customer's region should be attached to this response rather than paraphrased.

Per-endpoint rate limits and page-size caps are not published in openly available documentation; the interactive API reference is available to authenticated tenants. Integrators consistently report per-endpoint throttling that requires request batching and caching. We recommend measuring observed throughput within the customer's own tenant during evaluation and designing the integration against that measurement, and we will provide that measurement as part of a proof of concept.

Yes. Typed custom fields can be written from scripts running on the endpoint or through the API, and those fields can then be evaluated as monitoring conditions. This allows a business or compliance attribute to drive alerting directly rather than being maintained separately in a spreadsheet. Field types include checkbox, numeric, decimal, text, date and time, dropdown, multi-select, URL and encrypted text, each with defined format and length constraints.

Scope is expressed through an organisation, location and device hierarchy, and policy assignment resolves from organisation to location to device with the most specific assignment taking effect. A device holds exactly one effective policy at any time; policies are not merged or layered. Variation is authored at design time by deriving a child policy from a parent and changing only what differs. The practical consequence is determinism: the configuration applied to any device is a single object that can be opened and read, rather than a computed result that has to be reasoned about.

Four policy types cover distinct classes. Agent policies manage Windows, macOS and Linux endpoints. NMS policies manage agentless network infrastructure using SNMP and ICMP. VM policies manage virtualisation hosts and their guests. MDM policies manage Android, iOS and iPadOS without an installed agent. These are separate mechanisms with distinct condition sets rather than a single agent applied to different hardware.

Two backup types are available: image backup for full system recovery and file/folder backup for selective protection. Destinations may be cloud, customer network storage, or hybrid. Recovery paths include file-level recovery, image restore, bare metal recovery, and recovery to virtualisation. Backup health is evaluated as monitoring conditions covering job duration and time since last successful job, so backup status is surfaced in the same alerting model as the rest of the estate rather than in a separate console. Device backup and SaaS backup are distinct products protecting distinct workloads.

Patch approval supports automatic, manual, and reject states, allowing a staged deployment in which early groups are approved manually and observed before later groups deploy on schedule. Patch risk can be evaluated as a monitoring condition on CVSS score combined with the number of days a patch has remained pending, and separately on the age of pending patches per device. The vendor's guidance specifies a minimum interval of one hour between scan and installation; it does not prescribe group sizes or soak durations, which are an operating decision for the customer and which we would design jointly.

Mobile enrolment supports Apple iOS 10.0 and later, all iPadOS versions, and Android 8.0 (Oreo) and later. Remote access to managed mobile devices requires iOS 16.0 or later and Android 8.0 or later. Declarative Device Management requires iOS or iPadOS 17.0, or macOS 14.0; devices below those versions remain enrolled and managed under standard MDM behaviour. Automated zero-touch enrolment depends on Apple Business Manager, Apple School Manager, or Android Enterprise, which are vendor programmes the customer enrols in independently of the MDM platform.

Interactive sessions provide full desktop control. Background sessions run under the Windows SYSTEM account on a separate minimal desktop, allowing maintenance without interrupting the signed-in user; core administrative tooling including file browser, disk manager, registry editor, event viewer, service manager and command shells operate in this mode, while software that depends on the signed-in user's profile, profile-bound tokens, or interactive graphics may not launch. Agentless ad-hoc access is available for devices that have never been enrolled.