Current status
SOC 2: no report published yet. Independent penetration-test and insurance details are not published on this page.
AttestLayer Trust Center
Trust Center
This root-domain trust center explains AttestLayer's corporate identity, record-only product boundary, package integrity model, shared verification infrastructure, and first-party policies.
attestlayer.com is the corporate and trust site. Direct-client, partner, Console, Verify, Registry, and API tasks use their dedicated domains.
What the root domain is responsible for
attestlayer.com is the company-facing root domain. It explains product and verification boundaries, publishes trust and policy references, and routes visitors toward the public surface that matches their task.
Company-level trust and policy review is separate from the direct-client storefront and its commercial checkout.
Direct client service
Buyer Review Pack information, Fit selection, pricing, procurement, and direct ordering.
Partner program
MSP qualification, approved-pack distribution, and founding portfolio-design discussion.
Program design
Sponsor and program education, qualification, paid-design interest, and candidate governance using synthetic material only.
Verify
Check package membership, manifest-covered hashes, and issuer-receipt signatures.
Registry
Public issuer keys and explicit transparency status. Inclusion and continuity are not implied.
What reviewers can check
The package model is designed so covered bytes and an issuer receipt can be checked after delivery. The verifier recomputes file hashes, validates the canonical manifest, and checks the receipt against separately obtained issuer-key material. Files carried inside a package cannot establish their own trust.
- SHA-256 manifests enumerate the package-covered bytes.
- Ed25519 issuer receipts bind the canonical manifest digest.
- Receipt trust requires separately obtained issuer-key material.
- Registry inclusion and checkpoint continuity are separate from package integrity and must not be inferred.
A clearly labeled sample can demonstrate the verification flow without being presented as customer evidence, an audit result, or a customer outcome.
Synthetic sample
Inspect the published sample and its verification boundary.
Order and security package
Short review packet for procurement, security, or partner review.
Browser verifier
Open the shared browser verification utility.
Registry material
Review public issuer keys and explicit transparency capability status.
Operating model and boundaries
AttestLayer provides a narrow record-only evidence-packaging model. It is not an audit firm, certification body, or agent deployed inside a customer's systems.
- The standard record-upload design is intended not to require customer production-system, API, credential, or endpoint-agent access.
- Customers remain responsible for authorization, accuracy, completeness, and appropriate sharing of supplied records.
- Unsupported requirements remain visible rather than being silently inferred.
- Package verification does not establish record truth, control effectiveness, compliance, certification, or approval.
That operating boundary is what lets trust review, policy review, and commercial review stay legible across separate public surfaces.
Security, disclosure, and policy references
Trust on the root domain is backed by published policies that are specific to AttestLayer's first-party web surfaces rather than copied from the direct-client storefront.
Security
Infrastructure posture, operating model, and cryptographic trust material.
Privacy
How AttestLayer handles root-site usage and correspondence data.
Subprocessors
Current third-party providers used to operate first-party surfaces.
Vulnerability disclosure
How security researchers can report issues to AttestLayer.
Security issues and trust questions can always be routed to security@attestlayer.com.
Record-only boundary
Standard AttestLayer workflows are designed around records the customer is authorized to provide without endpoint installation or production credentials. Package verification can establish integrity and issuer-receipt authenticity; it does not establish the truth or completeness of supplied records, control effectiveness, compliance, certification, legal sufficiency, or customer approval.