The hidden requirement in every identity platform: an internet connection

Identity is the way into a modern enterprise, and nearly every tool built to defend it assumes it can call home, which rules those tools out of exactly the environments that need them most.

Where the assumption breaks

Identity is the dominant path into an enterprise, and the market has responded with a generation of excellent tools. Almost all of them are SaaS. They ship a collector into your environment, that collector posts to a cloud backend, and the analysis, the graph and the console live somewhere you do not control.

For most organisations that is a reasonable trade. For some it is simply not available. A defence contractor working on a classified programme, a power utility whose control network is air-gapped by regulation, a hospital whose clinical segment has no route to the internet, a government tenant whose data cannot leave a jurisdiction: for all of these, egress is not a preference to be configured. It is forbidden.

The result is a gap: the environments with the strictest requirements are the ones least well served by the tooling built to meet them. Air-gapped identity security exists to close it.

What actually has to change

The analysis has to run where the data is

If nothing can leave, the graph engine, the rule set and the scoring all have to execute inside the perimeter. That means shipping the intelligence rather than the telemetry: a posture rule set that is complete on the appliance, updated by a signed offline bundle rather than by a nightly pull. AphelioNYX is built this way: a sensor appliance, a backend with the graph engine, and a command centre, all on your side of the boundary.

Attack paths matter more, not less

The interesting question in Active Directory has never been “which accounts are misconfigured?”; it is “which chain of misconfigurations reaches Tier-0, and which single link breaks the most of them?”. A Kerberoastable service account is a finding. A Kerberoastable service account that can enrol against a certificate template with an enrollee-supplied subject, which authenticates as a domain controller, which holds replication rights, is a path to Domain Admin. AphelioNYX documents an average of five hops on the paths it graphs.

Graphing that requires the whole directory in one place. It does not require the internet.

OT changes the shape of the problem

In an industrial environment, discovery cannot be active. You cannot scan a PLC that is controlling something physical, and an aggressive fingerprint can take a line down. Passive protocol identification (Modbus, OPC-UA, EtherNet/IP, DNP3, S7, BACnet, IEC 60870-5-104) placed onto a Purdue model tells you what is there and, more usefully, what is talking to something it should not be. See OT and ICS security for how that engagement runs.

Findings need a lifecycle, not a dashboard

A finding nobody acts on is a log line. Offline or not, the tooling has to carry a severity, an owner, a service-level target and a route into whatever ticketing system the organisation actually uses. We work to seven days on critical findings, thirty on high, sixty on medium and ninety on low, and the number that matters is not how many findings were produced but how many were closed inside those windows.

What you give up

Honesty is more useful here than a sales pitch. Running offline costs you the things a cloud backend does well: instant global threat intelligence, telemetry pooled across tenants, and updates that arrive without anyone carrying them in. Rule updates become a logistical process with a person attached. Capacity has to be planned rather than rented.

For an ordinary enterprise, those are real losses and a SaaS platform is the better answer. For an environment where outbound traffic is prohibited, they are not losses at all. They are simply the conditions, and the alternative is not a cloud tool, it is a spreadsheet.

How to tell which you are

Ask one question of your own network: if a collector on the domain controller attempted an outbound TLS connection to a vendor endpoint, would it succeed, and would anyone be told? If the answer is “yes, and nobody would notice”, you have a monitoring problem worth solving before you buy anything. If the answer is “no, and correctly so”, then the tooling you evaluate has to work under that constraint, and most of it does not.

Our identity and access management practice starts with that question, and the answer determines the architecture rather than the other way round.