Skip to content

A security model stated precisely enough to argue with.

TLS, TOTP two-factor, secure cookies, and a WAF are table stakes and are in place. They are not the interesting part, and a page that leads with them is telling you it has nothing else to say. The first section below is the one an aerospace program asks about, so it is first.

Export control

What IPAC holds, and what it will not hold.

IPAC stores metadata, cryptographic hashes, and non-technical documents. It does not host ITAR-controlled technical data. Drawings, models, analysis, and test data stay in your systems; IPAC references them by SHA-256 digest, so a decision record can prove exactly which revision it was made against without the file ever leaving your control. The hosting reality behind that statement: IPAC runs on Google Cloud in us-central1, with no Assured Workloads enclave and no US-persons access control. If your program requires either, IPAC is not the place to put controlled technical data today. We would rather say that here than have you find it in week six.

Stored in IPAC

  • Part numbers, serial numbers, revisions, and lot numbers
  • Vendor identity, approval status, and qualification expiry
  • Document titles, types, versions, and SHA-256 digests
  • Nonconformance numbers, dispositions, and Material Review Board approvers
  • Mission identifiers, vehicle identifiers, and window dates
  • Certificates of conformance and material certifications, where they are not themselves controlled technical data

Never uploaded to IPAC

  • Engineering drawings, CAD models, and specifications
  • Test data, analysis reports, and qualification test articles
  • Flight software, firmware, and source code
  • Any other technical data controlled under the ITAR or the EAR

Where it runs

  • Google Cloud, us-central1. No Assured Workloads, no GovCloud, no sovereign region.
  • No US-persons access control on support or administration.
  • Not FedRAMP authorized. No CMMC assessment. No DoD impact-level accreditation.
  • Data residency outside the current region is a scoping conversation, not a configuration switch.

Tenant isolation

A tenant is the unit of reach. Membership decides which records a user can address at all, and entitlements are granted per tenant, not globally, so a new capability is a grant instead of an exposure.

  • Per-tenant membership and per-tenant module entitlements
  • Tenant-scoped records across every surface
  • Subscription and trial state held per tenant

Environment separation

Inside a tenant, demonstration data and operating data are different worlds. Requests carry the environment they act in, and records are scoped to it. A demo can never contaminate a flight-readiness record.

  • Environment-scoped data model
  • Per-environment document, qualification, and vendor-type definitions
  • Object storage partitioned by tenant and environment

Controlled access

Sessions are held server-side and expire on a fixed schedule, so revocation is real, not advisory. Programmatic access uses scoped keys instead of borrowed user credentials.

  • Email and password with per-user TOTP two-factor
  • Role-based permissions for administrative functions
  • Server-side sessions with fixed expiry
  • Scoped API keys for programmatic access

Evidence integrity

Evidence is append-only in effect. Every document is hashed on upload and superseding one creates a version instead of overwriting it. The readiness call made six months ago still points at the certificate it was actually made on.

  • SHA-256 digest computed and stored at upload
  • Versioning preserves superseded documents and their review state
  • Evidence linked to the decisions that cite it
  • Records anchored in an append-only SHA-256 chain, each entry chaining to the previous

Auditability

The question is never 'what does the system say now'. It is 'what did it say then, and on what basis'. Decision-relevant and security-relevant activity is retained so that question has an answer a prime or an auditor can follow.

  • Authentication and login event history
  • Evidence review state and version history
  • Case activity and decision records retained
  • Webhook delivery history for integrated systems

External verification

Some claims have to be checkable by someone who will never have an account. A verification page is addressed by an unguessable token and exposes exactly one claim. Nothing about the tenant, the platform, or anything adjacent.

  • Token-addressed public verification pages
  • Verification tokens never returned by list endpoints without authorization
  • Downloadable verification certificates

The narrowest possible public surface.

A part pedigree page is the only part of IPAC an unauthenticated stranger can reach. It is addressed by an unguessable token, exposes exactly one claim, and reveals nothing about the tenant, the platform, or any adjacent record. It carries metadata and digests, never the documents themselves. Verification tokens are never returned by list endpoints without authorization.

/verify/part/51595c91…
Pedigree verified
Confirmed 2026-08-15 · 04:12 UTC
Part number
MV1-TPS-0142
Serial number
SN 0007
Revision
C
Approved vendor
Tessera Composites
Vendor qualifications
AS9100D · NADCAP composites
Lot
TPS-LOT-2291
First article
AS9102 FAI accepted 2026-05-18
Installed on
MV-1 · aeroshell station 4
Documents on file
  • Certificate of conformance
    v2 · reviewed
    77ff05b2…a5035dverified
  • Material certification
    v1 · reviewed
    c41a9de0…12bb47verified
  • FAI report (AS9102)
    v1 · reviewed
    5b20e7c4…9d0f31verified
Certificate of conformance (SHA-256)
77ff05b24dc3c187acb74031955de4811ebfbcb22c566c17f69e79f9bea5035d

Metadata and digests only. No drawing, no analysis, no test data. Those stay in the operator’s systems and are referenced here by hash.

Public pedigree page at /verify/part/:token. Reference environment data.

What we do not claim.

A security claim is only useful if it is precise. Everything below is something a competitor would leave for you to discover in week six of a procurement cycle. Here it is in minute one, so you can price it into the decision or walk away early.


IPAC is not an ITAR enclave.
There is no Assured Workloads boundary and no US-persons access control. Controlled technical data belongs in your systems and is referenced here by digest. The full posture is stated above rather than left to a questionnaire.

Two-factor is per user, not enforced tenant-wide.
TOTP two-factor is implemented and can be enrolled by any user. Enforcing it for every member of a tenant is an onboarding commitment we make in writing, not a switch in the product today.

Single sign-on is not available.
SAML and OIDC are not implemented. Authentication is email and password with per-user TOTP two-factor.

Anchoring is a hash chain, not a public blockchain.
Records are anchored in an internal append-only SHA-256 chain. Nothing is written to an external or public distributed ledger, and this is not equivalent to third-party timestamping.

Isolation is enforced by query scoping.
Tenant and environment separation is enforced in the application layer, not by physical database separation. We describe it that way instead of as an absolute guarantee.

We do not hold an ISO 27001 certificate.
SOC 2 is the attestation we hold. ISO 27001 is not in place, and control questions outside the SOC 2 scope are answered directly, in writing, during evaluation.

Deployment posture, data residency, and controls specific to a regulatory environment are scoped during evaluation. If you hold a control requirement not described here, raise it and you will get a direct answer, not a roadmap.

Independently examined under SOC 2 Type 1 and Type 2 by Sensiba.

Criteria
Security, Availability, and Confidentiality
Type 2 period
March 5 to June 5, 2024
Service organization
Schubring Global Solutions

Schubring Global Solutions, which operates the platform IPAC runs on, completed SOC 2 Type 1 and Type 2 examinations performed by Sensiba, an independent service auditor. The Type 2 examination covered the trust services criteria for Security, Availability, and Confidentiality across the period March 5 to June 5, 2024, testing whether the controls actually operated rather than whether they were merely designed well.

  • The Type 2 period closed in June 2024 and has not yet been refreshed. A new examination is intended, and until it completes we describe the attestation in the past tense.
  • Processing Integrity and Privacy were not in scope. The applicable criteria were Security, Availability, and Confidentiality.
  • The report uses the carve-out method for the subservice organizations providing application maintenance and support, and assumes complementary user entity controls at your end. It identifies which.

Ask for the report at [email protected].

We would rather answer a hard security question early than late.

Send the questionnaire before the demo if that is the order that suits you. Direct inquiries reach us at [email protected].