Endpoint Platform Architecture: An Evaluator’s Guide

Endpoint management platforms differ far more in architecture than their feature matrices suggest. Two products can list the same twenty capabilities and behave completely differently in an estate with segregated networks, unreliable links and a change-control process. This guide describes the choices that matter and how to test them during an evaluation.

Connectivity: outbound versus listening

The first and most consequential choice is direction. Either the agent connects outbound to the platform and holds that connection, or something connects inward to the endpoint — directly, or via an on-premises relay or appliance.

Outbound-only means no listening service on managed machines, no inbound firewall rules, no exposure created by a change made for an unrelated reason, and no VPN requirement to reach a machine on a segregated network. It also means the platform depends on the endpoint maintaining a connection, which makes middlebox behaviour — proxies and firewalls that terminate long-lived connections — a real operational concern rather than a theoretical one.

AegisOne is outbound-only. During any evaluation, establish which model a vendor uses and, if there is a relay or appliance, what it exposes, where it must sit, and who patches it. An on-premises component in a management chain is a piece of infrastructure you now own, and it will still be there in five years.

Agent implementation

A compiled binary with no runtime dependencies behaves differently from an agent that requires an interpreter or framework. The difference shows up on the machines you least want to touch: appliances, long-lived servers, and anything behind a change-control gate. An agent that drags a runtime along brings that runtime's vulnerability stream and update cadence with it, and you will be answering questions about both.

Architecture support is worth checking specifically rather than accepting as a platform list. "Supports macOS" can mean an Intel build running under translation on Apple Silicon. That may be acceptable, but it should be a decision rather than a discovery. AegisOne ships native builds for Windows, Linux, macOS arm64 and macOS amd64.

The action surface

What can the platform actually cause to happen on an endpoint? This is a security question and a capability question at once, and the two pull in opposite directions.

A fixed action surface — a defined set of operations such as scan, install, uninstall, remediate, open a session — is bounded and analysable. You can enumerate what the platform can do, which means you can reason about the consequences of a console compromise. AegisOne has a fixed action surface; there is no script library and no user-authored automation.

An arbitrary-code surface is more capable and unbounded. Any platform that lets an operator run authored PowerShell or Bash on endpoints is, architecturally, a remote code execution capability across your estate by design. That is often a worthwhile trade, but it should be an explicit one, and the controls sitting between a console session and production execution deserve real scrutiny.

Data model

The structural question is whether the platform models a hierarchy of clients, sites and departments as a first-class concept, or whether it models a flat list of machines with tags applied. Tags are flexible and rot. A hierarchy is more rigid and holds its shape, and it can carry scoping, reporting and commercial context in a way tags cannot.

A related and frequently overlooked question is whether an asset is distinct from an endpoint. If they are the same record, rebuilding a machine restarts its history — which means the platform cannot answer "what has happened to this device over its life", only "what has happened since the current operating system was installed". AegisOne holds an asset record with its own timeline, separate from the endpoint record bound to an OS install.

Also ask whether discovered devices are held apart from managed ones. When they share a list, someone eventually reports a combined figure as devices under management, and it reaches a customer.

Where state lives

Inventory, health history and patch position all have retention characteristics, and vendors are frequently vague about them. Ask how long history is retained, whether retention differs by data type, and what happens to it when a machine is removed from management.

This matters most for compliance. Evidence you cannot produce for the period in question is not evidence. A platform retaining ninety days of history cannot support an audit covering a year, regardless of how good its reporting looks in a demonstration.

Integration surface

Assume every endpoint platform sits inside a toolchain rather than replacing one. The practical question is whether the API exposes the same surface the console uses, or a reduced subset that covers reads but not operations.

A full API is what lets you compensate for gaps. AegisOne has no alerting engine; teams that need paging poll the API from the alerting platform they already run and evaluate conditions there. That arrangement is only possible because the data is reachable programmatically, and it is worth confirming with any vendor before assuming a gap is bridgeable.

How to test all this

Do not evaluate in a clean lab. Deploy into your most awkward environment — the segregated network, the site with the bad link, the machines behind a proxy that inspects traffic. Those environments are where architectural differences become visible, and they are where a product that demonstrated beautifully will either hold up or fall over.

Then leave it running for longer than feels necessary. Most architectural problems in this category are not visible in week one. They appear in week six, when history has accumulated, connections have been dropped and re-established a few hundred times, and someone asks a question that requires the platform to remember something.