Security architecture overview

Start with the identities and data involved in your workflow. Then review the access, network, storage, and integrity controls that protect each step.

Use deployed configuration and test results to confirm those controls. The architecture describes their intended roles, not the result of a customer deployment review.

Review the boundaries

Trace submitted fields, stores, background work, exports, and proof data.Data flow Review Azure service responsibilities and validation points.Infrastructure Validate tenant, application, role, audit, database, and privileged access.Isolation Understand Solana and Azure SQL Ledger verification boundaries.Evidence integrity

Operating models

Managed SaaS runs within the VeriProof service boundary. Customer-managed Azure places supported services and stores in the customer’s subscription.

Customer-managed Azure does not imply a hash-only data flow. Confirm every network path and external dependency in the approved architecture.

Record the decisions

For each answer, name the responsible owner and the evidence that supports it:

Which identity authenticates each user, application, workload, connector, and service?
Which tenant, role, application, and audit scope applies?
Which fields leave the customer application?
Where are records, secrets, logs, backups, and exports stored?
Which privileged paths can bypass normal scope?
Which proof provider is selected, and how will an auditor verify it?
Who owns monitoring, incident response, restore, key rotation, deletion, and upgrades?

Architecture intent is not deployment evidence. Confirm the target environment through configuration, authorization tests, data inspection, restore tests, and provider verification.