Security
Air-gapped by construction.
Aplark Assure is built for machines that have never had a route to the internet. Not "supports offline mode" — there is no configuration in which it reaches out.
No outbound connection, under any configuration
There is no telemetry, no licence callback, no update check, no crash reporter, no analytics and no content delivery network. The installation does not resolve a name it was not configured with, and there is no flag that turns any of this on.
This is enforced rather than asserted: the runtime is executed in a network namespace with no route, and a continuous integration check fails the build if any component attempts a connection during its test suite.
Offline installation and update
Installation proceeds from a signed offline bundle onto a machine that has never had internet access, with all container images pinned by digest. Updates arrive the same way — as a bundle that is verified before it is applied, never as a fetch.
Key custody separated by design
The installation root key lives in a hardware security module. Ledger, attestation and gate-authority keys are derived from it, with the gate authority held under separate custody so that the party producing evidence cannot also approve the deployment that cites it.
Separation of duties is verified during commissioning with a negative test: an operator who created a piece of evidence attempts to approve the gate, and is refused.
Evidence that outlives the vendor
The export bundle is self-contained and verifiable offline with a free static binary. A reviewer with no account, no documentation beyond the tool’s own help output, and no network can check every claim in a dossier on a machine that has never contacted us.
That property is deliberate and commercially inconvenient. It is also the only honest answer to the question a certification authority will ask about vendor dependence.
Audited access, minimum retention
Role-based access control maps one-to-one onto the product’s personas, every read of programme data is written to an append-only audit log, and the audit log is exportable for accreditation review.
Accreditation posture
A security architecture document is produced for the accrediting authority, describing the trust boundaries, key custody model, data flows and the negative tests demonstrating the separation of duties. It is handed over as part of commissioning rather than assembled on request.
We do not claim any accreditation we do not hold. Where a programme requires one, the honest position is that the platform is designed to be accreditable in that environment and the accreditation itself is the customer’s, granted by their authority.
This website holds itself to the same standard
The site you are reading makes no third-party browser request of any kind. No hosted fonts, no analytics, no tag manager, no captcha, no chat widget, no embedded video, no map, no library served from a content delivery network. Every asset is served from this origin.
Two checks in the build pipeline enforce it: a parser that fails the build if any external URL appears in the compiled output, and an end-to-end test that loads every route with request interception and fails if a single request leaves this origin.
The audience for this site is defence procurement. Leaking a record of their visit to a foreign server would contradict the product being sold, and they will check.
Reporting a vulnerability
Security issues can be reported to the address below. We will acknowledge receipt and keep you informed through to resolution. Please do not include classified or export-controlled material in an initial report.
security@aplark.com