HBX Labs Logo
HBXLabs
An old basement equipment room: open racks, tangled cabling and a single fluorescent tube.

HBX vs. cloud infrastructure identity

Cloud and workload identity vendors built real machine identity. The question is where it stops.

They are good inside one directory or one cloud account. HBX starts where that stops: on systems never built for the web, and for the caller who isn't yours, with the human behind the agent approving each time.

Cloud versus on-premise

Cloud identity covers cloud workloads. Your plant and telco systems need something else.

One side is optimized for infrastructure that was designed after modern sign-in existed. The other has to work on equipment that predates it and will outlive it.

Modern identity can be layered onto a product that already reaches hard targets. The reverse is much harder.

Cloud agent identity reaches modern APIs and cloud infrastructure and stops at the edge of the customer’s network. HBX Access authorizes access across that edge.Both halves are drawn the same above the line: an agent holding a modern cloud identity, reaching a modern SaaS API and cloud infrastructure with solid arrows. Below both halves is the customer’s private network, holding AS/400, Oracle, mainframe and SCADA. On the left, labelled cloud agent identity, a thick line drops from the agent and stops dead against a heavy boundary line marked where the web ends; there is nothing below it that can receive a modern sign-in. On the right, labelled with HBX Access, a straight line drops from the agent, crosses the boundary where the left line stops, and reaches a connector just inside the customer’s network, which fans out to all four legacy systems. HBX Access is drawn above the boundary, off the traffic line, with a dashed arrow showing that it authorizes the connector; the connector opens a temporary login on the target because it speaks the target’s own language.CLOUD AGENT IDENTITYthe identity agents already carryAgentcloud identityModern SaaS APIsCloud infrastructurethis part already works, and works wellWHERE THE WEB ENDSAS/400OracleMainframeSCADAWITH HBX ACCESSthe same agent, plus authorization for each jobAgentcloud identityModern SaaS APIsCloud infrastructurethis part already works, and works wellWHERE THE WEB ENDSAS/400OracleMainframeSCADAthe identity gets this far and stopsno modern sign-in: nothing to present an identity toIt works, right up to the edge.Below the line there is no identity layer to talk to.ConnectorHBX AccessHBX authorizes; the connector opens a temporary loginThe same agent, one step further.Across the edge, into what was never going to speak the web.Cloud agent identity isn’t wrong. It just stops where the customer’s network begins.

Where the line falls

Where cloud identity stops: the human check and the company boundary.

The line falls where each job has to be approved again, or where the caller stops being yours.

01

The human link is set once, not per session

Cloud identity registers an agent against a responsible person once, at setup, and keeps the chain of who acts for whom traceable. After that the agent works without anyone being asked again, and the destructive action on the eleventh run looks exactly like the first.

02

One trust domain, by design

Cloud identity is built around the identities in one directory. The case it wasn't built for is the caller that belongs to an MSP, a consultancy, or a vendor serving many customers while the target belongs to you.

Already running one of these? The thirty minutes worth having is about the jobs they weren't built for: the ones crossing a boundary or landing on equipment that has never heard of modern sign-in.

Talk to us for 30 minutes See the demo