Security
How Hangar keeps one customer's job apart from the next, where every kind of data lives, and the timings Hangar keeps when an advisory lands.
The reset between customers
The switchover between customers is the security boundary. Hangar publishes each step of the switchover.
The previous job ends.
Its process tree and container are stopped. Outputs and checkpoints are sealed to Sydney storage and their digests recorded.
The instance is terminated, not reused.
Each slot runs on a freshly launched instance inside the capacity block, from the Hangar image. Nothing from the previous customer's operating system, filesystem, kernel state or GPU driver state survives, because the machine itself does not survive. If the relaunch fails, the fallback is a reboot in place and the certificate says so.
The working disk ends with the instance.
Customer data during a job lives on the instance's local NVMe under a second encryption layer whose key exists only in RAM, on top of the hardware encryption whose keys AWS destroys at termination. The root volume holds only the image and is deleted with the instance. No customer data is written to EBS. Each step is recorded.
The new instance proves what it is.
The image boots under UEFI Secure Boot with Hangar's keys from a read-only verified root, and NitroTPM measures the boot. At slot start the instance returns a Nitro-signed attestation over a nonce the control plane chose, and the control plane compares the boot measurements with the signed reference values for the release. The instance never reports its own digests. The attestation digest goes on the certificate.
The GPU is checked and scrubbed.
Before any customer code, the GPU's firmware, driver, ECC counters and remapped rows are compared with the signed manifest for the block, no process may hold the device, and all free device memory is filled with zeros and read back. The vendor's short diagnostic and health check run, then persistence mode starts. Any mismatch, pending remap or uncorrected error fails the slot closed and alerts the operator. Driver and firmware reserved memory, on-chip state and the firmware images are verified against the manifest.
The network and the credentials are fresh.
Each slot has its own security group with no inbound access, egress limited to the account's allowlist and Sydney storage, and instance metadata locked to version 2. The instance holds no role: the worker receives credentials scoped to the slot's storage prefix and image for 15 minutes, issued after the attestation passes, and containers cannot reach the metadata endpoint.
The wipe record is written and signed.
Before the next customer's data is mounted, the wipe record names the instance ids, the attestation, the scrub result, the release manifest digest and the times. It is part of the next job's certificate.
This reset defends against data left in GPU memory or on disk from the previous customer, a poisoned driver or operating system, a process surviving across slots, and a route between customers.
The physical security of the hosts in the data centre, and the hypervisor itself, are AWS's responsibility under its shared responsibility model.
Read how a job is isolated, in the docs.
Where your data lives
One rule for every category: Sydney only, under keys Hangar or you hold, no US service in the path, and every move that matters recorded on a certificate.
| Category | Where it lives | Keys | Who can read it | Kept for | Recorded as a data move |
|---|---|---|---|---|---|
| Your secrets: API keys, tokens and database credentials a job needs | A secrets store in ap-southeast-2, sealed per customer | Your data key; Hangar cannot read the values | The job, at mount, as environment or file | Until you delete or rotate them | Yes: the names are recorded, never the values |
| Job logs, stdout and stderr | Streamed to you over TLS, stored in Sydney object storage | Your data key | You | 90 days, or earlier on request | Yes: stored, downloaded, deleted |
| Checkpoints and outputs | Sydney object storage, versioned, with object lock | Your data key | You | 90 days, or earlier on request | Yes: written, downloaded, deleted |
| Container images, your layers | A registry in ap-southeast-2, content-addressed | Hangar's storage key | The worker, at pull | As uploads: 30 days after the last slot | Yes: received, staged, mounted |
| Base images: public CUDA, Python and model images | Mirrored into a Sydney cache once; your layers are built on the mirror | Public content | Everyone | Hangar's choice | Inbound public content, outside your data |
| Snapshots | Customer instances are never snapshotted. The working disk is the instance's local NVMe, encrypted by the hardware with keys AWS destroys at termination | Hardware keys destroyed at termination | Nobody after the slot | Zero | Yes: the wipe record names the instance, the volumes and the method |
| Hangar's operational logs | Self-hosted in Sydney; metadata only, payloads redacted at source | Hangar's keys | TALOS Defence operators, Australian citizens | 12 months | Outside your data by construction; the daily audit log digest is attached to certificates |
| Metrics and error tracking | Self-hosted in Sydney, scrubbed of identifiers | Hangar's keys | Operators | 90 days | Outside your data |
| The control-plane database: accounts, bookings, records and tree heads | ap-southeast-2, encrypted, replicated across availability zones, backed up in-region only | Hangar's keys | Operators | Records indefinitely; backups 35 days | Tree heads are published by design |
| Transactional email | Sent from Sydney through a mail service in ap-southeast-2, with links and metadata only | Not applicable | You | Gone after delivery | Outside your data |
| Payments | The payment processor sees the ABN, the card and the invoice, never a workload or a file | Not applicable | The processor | Per its terms | Outside your data |
| Support | Email in TALOS Defence's Australian tenant; we never ask you to send data, logs or secrets | Not applicable | Operators | Per the tenant's rules | Outside your data |
| DNS and TLS | TLS terminates in Sydney on Hangar's own endpoint; no third-party proxy terminates your connection offshore | Hangar's certificates | Not applicable | Not applicable | Outside your data |
| Source code and builds | A code host that holds no customer data; builders run in Sydney; releases are signed and reproducible | The release signing key, held by TALOS Defence | Public for the verifier, private for the rest | Indefinitely | Outside your data |
| Encryption keys | Client-side envelope encryption: a per-object AES-256-GCM key, wrapped by your key, wrapped by a Hangar root in a YubiHSM 2 pair at two Australian-owned Sydney sites | The root never leaves the module | Nobody reads keys; the module uses them | Per the rotation policy | Key use at mount is recorded as an event, never the key |
Never in the path: US-hosted log, metrics or error services; US form or analytics tools; offshore support staff with access; AI assistants with access to customer data; a global edge that terminates TLS outside Australia.
Security advisories and maintenance
Hangar states these timings so you know before booking what happens when a vulnerability or an advisory lands.
| Trigger | What Hangar does | Within |
|---|---|---|
| An ASD or ACSC advisory, or a vendor advisory, for a vulnerability that is exploited or critical in the image, the driver, the runtime or the control plane | Rebuild and release the image or the service; terminate affected instances if the advisory requires it | 48 hours |
| Any other vulnerability in those components | Rebuild and release | 14 days |
| An advisory that requires Hangar to take a tier or the whole service offline | The status page says so with the advisory reference, affected bookings are credited in full, checkpoints and certificates issued to that point are preserved, and customers are told by email | Status page within 1 hour of the decision; email within 4 hours |
| A vulnerability reported to Hangar through security.txt | Acknowledged, assessed and fixed on the timings above, and the reporter told | Acknowledged within 1 business day |
| Planned maintenance that stops a tier | Announced on the status page and by email, outside every sold slot | 7 days ahead |
Each instance lives for one slot and is replaced, so a release reaches every slot in the next block.
To report a vulnerability, use the contact in security.txt
Subprocessors
In the data path
- Amazon Web Services, Asia Pacific (Sydney) region: compute, storage, the registry and secrets.
Outside the data path
- Stripe: payments. Stripe sees the ABN, the card and the invoice, never a workload or a file.
- Amazon Web Services billing: billing metadata, processed globally.
- Amazon Simple Email Service in ap-southeast-2: transactional email with links and metadata.
- Microsoft 365, TALOS Defence's tenant, stored in Australia: support email.
Posture
TALOS Defence Pty Ltd is 100% Australian-owned and controlled.
TALOS Defence's Essential Eight posture is self-assessed at Maturity Level Two.
Hangar's operators are Australian citizens and sign in with hardware security keys.
A job certificate states facts about a job: what ran, on what, when, and every move of its data. Your assessor draws the conclusion.
Support and end of life
Hangar is supported until 5 November 2031. Until that date TALOS Defence provides security updates and support for the service and its software. The date only ever moves later.
Every job certificate stays verifiable for at least seven years from issue. TALOS Defence keeps the published keys, the tree heads and the verifier available from its own domain for that whole period.