Security & Trust

Last updated: 2 June 2026

Looking for the quick trust overview procurement teams use? Visit the Security Trust Center. Researchers can also review security.txt.

1. Our Commitment

AffixIO provides stateless yes/no eligibility verification and cryptographically signed proofs for organisations that cannot afford to centralise sensitive identity data at every verification hop. Security is foundational to that promise: if verdicts or proofs can be forged, tampered with, or extracted at scale, the platform fails its purpose.

This page describes technical and organisational measures we apply to the Services. It is informational and does not modify contractual commitments in an enterprise Order or DPA unless incorporated by reference.

Trust summary: encryption in transit, hardened verifier boundaries, no PII retention at the verifier by default, signed proofs with key rotation, and incident response processes aligned to customer notification obligations.

2. Security Model

AffixIO separates concerns across three layers:

Control plane: account management, API key issuance, policy configuration, billing, and audit dashboards. Access is restricted to authenticated personnel and customers with role-based permissions.
Verification plane: stateless evaluation engines that process eligibility inputs, return yes/no verdicts, and optionally emit signed proofs without retaining PII by default.
Trust plane: signing keys, proof verification endpoints, transparency documents, and revocation/status mechanisms.

Compromise of one layer should not automatically compromise the others. Keys for proof signing are isolated from general application databases.

3. Architecture and Data Flow

Typical production flow:

Customer application sends a minimised payload to AffixIO over TLS.
Verifier evaluates configured circuits against supplied attributes or tokens.
AffixIO returns a verdict and optional signed proof to the customer.
Underlying PII, if any entered upstream, is not persisted at the verifier under default settings.
Customer stores proofs or logs according to its own retention policy.

3.1 Isolation

Production workloads run in logically separated environments from development and sandbox. Customer data paths are segmented to prevent cross-tenant access. Multi-tenant architectures employ strict identifier scoping on every query and cache key.

3.2 Supply chain

We maintain inventories of dependencies, monitor advisories, and patch critical vulnerabilities on prioritized schedules. Container images and infrastructure modules are versioned and reviewed before promotion.

4. Encryption

4.1 In transit

All public API and dashboard endpoints require TLS 1.2 or higher with modern cipher suites. Internal service-to-service traffic uses encrypted channels within the production boundary.

4.2 At rest

Databases, object stores, and backups containing customer configuration, operational logs, or optional retained artefacts are encrypted at rest using industry-standard algorithms and provider-managed or customer-managed keys where offered.

4.3 Secrets

API secrets, signing keys, and administrative credentials are stored in dedicated secret management systems with access logging and rotation procedures.

5. Signing Keys and Proof Integrity

Signed proofs use asymmetric cryptography. Private signing keys reside in hardened storage; public keys are published for customer verification. We support scheduled rotation with overlap periods so customers can update trust stores without downtime.

Proof payloads are canonicalised before signing to prevent ambiguity. Verification failures are logged for investigation. Customers should pin expected algorithms and key identifiers in their verification libraries.

AffixIO proofs attest to a verdict under a policy version at a point in time. They are not a substitute for your own record-keeping where regulation requires original documents.

6. Access Control and Identity

Dashboard access supports role-based permissions (admin, developer, read-only) where enabled.
API authentication uses scoped keys with least privilege; separate keys for sandbox and production are recommended.
Administrative access to production systems is limited to trained personnel, requires multi-factor authentication, and is logged.
Access reviews are conducted periodically; departed personnel access is revoked promptly.

7. Network Security

Production networks use defense-in-depth: firewalls, private subnets for data stores, egress filtering, and DDoS mitigation at the edge. Administrative interfaces are not exposed to the public internet without jump hosts or zero-trust access brokers.

Intrusion detection and anomaly alerting monitor for unusual traffic patterns, credential stuffing, and proof verification spikes indicative of abuse.

8. Application Security

Our secure development lifecycle includes threat modeling for new features, code review, static analysis, dependency scanning, and regular penetration testing by qualified third parties. Findings are tracked to remediation with severity-based SLAs.

8.1 API hardening

authentication on every request;
rate limiting and abuse detection;
input validation and schema enforcement;
strict CORS and security headers on web properties;
immutable audit trails for administrative changes.

9. Operations, Backups, and Availability

Backups are encrypted, tested for restore, and retained according to business continuity plans. Infrastructure is deployed across availability zones where supported. Enterprise customers may obtain detailed availability metrics under NDA or in an Order.

Changes to production follow change management with rollback capability. Emergency changes are documented post-incident.

10. Incident Response

AffixIO maintains an incident response plan covering detection, containment, eradication, recovery, and notification. Security incidents involving personal data are reported to affected enterprise customers without undue delay and within timeframes specified in the DPA, typically within 72 hours of confirmation where GDPR applies.

Status updates for widespread service events are published on the service status page. Customers should subscribe for operational notices separate from security advisories.

11. Responsible Disclosure

We welcome reports from security researchers. Submit findings through the Contact Us page with the subject line “Security disclosure” and include reproduction steps, impact assessment, and proof-of-concept if available. Do not access customer data, disrupt services, or publicly disclose before we have had reasonable time to remediate.

We do not pursue legal action against researchers who act in good faith within these guidelines. We may recognise valid reports at our discretion.

12. Compliance and Assurance

AffixIO aligns controls with widely recognised frameworks appropriate to our stage and customer requirements. Enterprise customers may request security questionnaires, penetration test summaries, and SOC or ISO reports where available under confidentiality.

Customers in regulated industries remain responsible for their own compliance programs. AffixIO provides artefacts to support due diligence but does not certify your deployment.

12.1 Payments and government

Payment users must maintain PCI scope reduction by not sending cardholder data to AffixIO unless explicitly designed and contracted. Government customers may require additional flow-down controls documented in the Order.

13. Customer Responsibilities

Security is shared. Customers must:

protect API keys and rotate on compromise;
configure circuits to minimise sensitive inputs;
verify signed proofs in application logic before relying on them;
maintain secure systems upstream and downstream of AffixIO;
train personnel on the Acceptable Use Policy;
notify AffixIO of suspected integration compromises promptly.

14. Infrastructure Providers

We use reputable cloud and security vendors subject to contractual security requirements. Sub-processor details are available to enterprise customers under the Privacy Policy and DPA. Customers requiring data residency or dedicated environments should discuss options during procurement.

15. Trust FAQ

Does AffixIO store personal data from checks?

By default, no PII is retained at the verifier after a verdict is issued. Operational metadata and optional proof logs may persist for security and billing as described in the Privacy Policy.

Can verdicts be replayed?

Customers should bind proofs to nonces, sessions, or transaction identifiers and reject replays outside documented time windows.

What happens if a signing key is compromised?

We rotate keys, publish revocation guidance, and notify affected customers. Proofs signed before rotation may require historical public keys for verification.

Is the API suitable for open client-side keys?

Never embed production API keys in public client-side code. Use server-side proxies or short-lived tokens issued by your backend.