JC!IJB! LogoJC!IJB!
Sovereign architecture

Sovereign by design.

No vendor cloud. No telemetry. No remote control. No mandatory online licensing. Signed offline updates. A deployed JC!IJB! system never has to connect to us — for anything.

Trust-boundary explorer

See every path that exists — and the ones that do not

Switch the options below to see which connections a deployment would have. This illustrates the architecture; it contacts no appliance.

Deployment options
Trust boundaries of a JC!IJB! deploymentInside the customer boundary: sensors, the appliance with its evidence store, policy boundary and actuators, and the customer administrator. Outside: the JC!IJB! vendor with no connection, optional customer-chosen intelligence feeds, customer export destinations, signed update bundles carried in by the customer, and the public website, which has no connection to any appliance.CUSTOMER BOUNDARY — customer-controlledSensors and agentsweb · DNS · firewall · endpointMirror / TAPpassive network copyCustomer administratormanagement networkJC!IJB! APPLIANCEHardened ingestionLocal evidence store (per host)Intelligence fusionPolicy boundaryGuarded actuatorsCustomer infrastructure the actuators may act onrefuse · throttle · challenge · isolate · revoke — within approved policyJC!IJB! vendorno telemetry · no access · no kill switchExternal intelligence feedschosen by the customerCustomer export destinationevidence bundles, reportsSigned update bundlecarried in by the customerPublic website (this site)no connection to any appliance

What leaves the appliance?AnswerDetail
Vendor telemetryNoneThere is no telemetry channel to JC!IJB!. Not for analytics, health, licensing or support.
Licence or activation checksNoneNo online licence verification and no activation server.
Remote commands or kill switchNoneJC!IJB! cannot reach a deployed appliance. There is no management path from the vendor.
Software updatesInbound only, offlineSigned bundles carried in by the customer on removable media, local upload or the customer's own repository.
Customer-selected external intelligence feedsOptional, directRequested by the appliance directly from the provider the customer chose — never routed through vendor servers. Off in air-gapped mode.
Customer exportsLocally initiatedEvidence bundles and reports leave only when the customer exports them, to a destination the customer chooses.
Public-website contactVoluntary, separateA message sent through this website is correspondence with JC!IJB!. It has no connection to any appliance.

Why no central server

A defence that depends on its vendor's servers inherits their outages, their jurisdiction, their staff and their compromise. A vendor that can switch a system off can be made to. JC!IJB! removes the path instead of promising not to use it.

What sovereignty does not mean

No central vendor server does not mean impossible to compromise. A sovereign system is defended by its own hardening, isolation, integrity checks, external assessment and the customer's operations — described plainly on the security page.

Evidence stays per host

Each protected server or site keeps its own history. Correlation happens inside the customer's domain, on the customer's side, by reading those histories over channels the customer initiates and pins.

Updates without a call home

Releases are signed bundles with published checksums. An ordinary browser may download them from this website; the appliance itself never contacts it and verifies the signature before anything is installed. How verification works.

SOVEREIGN BY DESIGN.

Request a technical briefing

Tell us what you need to protect. A briefing is an engineering conversation; it never needs your credentials, network inventories or logs.

Request a Technical Briefing View Sovereign Architecture