Status: pre-launch. This evidence reflects implemented code and deployed infrastructure. Provii is not yet serving end-user production traffic, so production operational metrics and audit history are not yet available.

Infrastructure Evidence Report

Author: Maelstrom AI Date: 2026-02-14 Scope: Infrastructure controls (UC-127 through UC-143) - Cloudflare Workers architecture Status: Evidence collection complete

Executive Summary

Mission

This report documents infrastructure-related evidence for the Provii zero knowledge age verification platform, focusing on the Cloudflare Workers-based architecture. The scope covers cloud architecture, data residency, network security, monitoring, DDoS protection, geographic distribution, and deployment practices.

Key Findings

Architecture Model: Fully serverless, edge-deployed on Cloudflare Workers. Infrastructure configuration (wrangler.toml, Terraform, CI workflows) lives in the application repositories (provii-verifier, provii-issuer, provii-management, and the other service repositories), not in the documentation repository.

Evidence Sources Examined:

• ISMS documentation at src/content/trust/
• Security policies and procedures
• Architecture documentation
• Business continuity plans
• Risk assessments

Important Context: This documentation repository is content-only. The operational infrastructure configuration (wrangler.toml, GitHub Actions workflows, deployment scripts) is held in the service repositories.

Control Coverage Status

Based on the evidence mapping document, the infrastructure controls (UC-127 through UC-143) were initially misidentified. The actual control numbers in the unified control matrix show:

• UC-127 through UC-140. Access & Identity Controls
• UC-141 through UC-143. Development & Operations Controls (SAST/DAST)

However, this report focuses on infrastructure-related controls as defined in the evidence mapping document, which covers:

• Cloud Architecture
• Data Residency
• Network Security
• Infrastructure Monitoring
• DDoS Protection
• Geographic Distribution
• Environment Separation
• Secrets Management
• CDN Configuration
• Deployment Architecture

Detailed Findings

1. Cloud Architecture

Evidence Source: src/content/trust/security/isms-scope.mdx

Infrastructure Model:

Cloudflare Services:
- Workers (edge compute environment)
- KV namespaces (distributed key-value storage)
- Durable Objects (stateful edge compute)
- Workers Assets (CDN for static assets)
- Workers Logs (structured log shipment to Grafana Loki)

GitHub:
- Source code repositories
- CI/CD workflows (GitHub Actions)
- Release artifact hosting
- Issue and project management

Build & Release Infrastructure:
- GitHub-hosted runners (ephemeral build environments)
- Sigstore services (Fulcio, Rekor) for artifact signing
- npm registry (JavaScript package distribution)

Architecture Characteristics:

• Serverless. No servers to manage, auto-scaling
• Edge-native. Code runs at Cloudflare’s 300+ global edge locations
• Stateless APIs. provii-verifier and provii-issuer are stateless Workers
• Distributed state. KV for configuration, Durable Objects for ephemeral state

Technical Components (from ISMS scope):

Status: ✅ Documented - Architecture well-defined in ISMS documentation

Gap: No access to actual infrastructure-as-code files (wrangler.toml) in this repository

2. Data Residency

Evidence Source: src/content/trust/security/isms-scope.mdx (lines 95-98)

Geographic Scope:

Primary Operations: Australia

Service Delivery: Global (Cloudflare edge network spans 300+ cities worldwide)

Data Residency:
- No PII storage (zero knowledge architecture)
- Infrastructure metadata resides in Cloudflare's distributed network
- Audit logs stored in Cloudflare KV (globally replicated)

Data Storage Locations:

• Cloudflare KV. Globally replicated, no specific data residency controls
• Durable Objects. Automatically placed in regions near users
• No PII. Architecture fundamentally avoids PII storage on servers

Key Finding: Zero knowledge architecture eliminates most data residency concerns because:

1. User PII (date of birth) is transmitted once during issuance for server-side Pedersen commitment computation, then immediately discarded; never transmitted during verification
2. Proofs are ephemeral and don’t contain PII
3. Only operational data (IP addresses, logs) stored server-side

Compliance Implication: Global distribution is a feature, not a risk, due to privacy-preserving design

Status: ✅ Implemented - Data residency addressed through privacy-by-design

Gap: No explicit documentation of Cloudflare data centre locations or regional compliance

3. Network Security

Evidence Source: src/content/trust/security/isms-scope.mdx (lines 206-213), src/content/trust/security/risk-methodology.mdx

Security Boundaries:

1. User → Wallet App: User controls device; we control app logic
2. Wallet → Issuer/Verifier: HTTPS + HMAC authentication
3. Relying Party → Verifier API: HTTPS + API key + HMAC auth
4. Developer → GitHub: SSH keys + 2FA + branch protection
5. CI/CD → Cloudflare: API tokens with minimal permissions
6. Cloudflare Workers → KV/DO: Internal Cloudflare bindings

Network Security Controls:

• TLS Everywhere. All external communications over HTTPS
• HMAC Authentication. API-level authentication (SHA-256)
• No network trust. Zero trust model - authenticate per request
• Cloudflare WAF. Web Application Firewall (implicit with Cloudflare)
• Edge termination. TLS termination at edge, close to users

From Risk Methodology (lines 397-407):

Cloud-Native Risks:

Advantages:
- No physical security concerns
- Enterprise-grade DDoS protection
- Automatic scaling and resilience

Challenges:
- Dependency on third-party availability
- Limited control over infrastructure
- Account security is critical

Zero Trust Architecture (from Control UC-133 research):

Evidence from control matrix:
- Micro-segmentation (environment separation)
- Per-request authentication and authorization
- No implicit trust based on network location
- Continuous monitoring and verification

Status: ✅ Implemented - Network security through Cloudflare platform + application-level controls

Gap: No network diagrams or detailed firewall rules (may be in application repos)

4. Infrastructure Monitoring

Evidence Source: src/content/trust/security/risk-methodology.mdx (lines 314-343)

Monitoring Strategy:

Ongoing Monitoring:

Key Risk Indicators:
- Failed authentication attempts
- Rate limit triggers
- Dependency vulnerability scans
- Service availability metrics
- Certificate expiration dates

Control Effectiveness:
- Security test coverage
- Audit log completeness
- Incident response time
- Patch management cadence
- Training completion rates

Regular Reviews:
- Quarterly: Review key risk indicators, update risk scores
- Annually: Full risk assessment, review all controls
- After Incidents: Root cause analysis, update risk assessment

Telemetry Infrastructure (from ISMS scope):

• Workers Logs. Cloudflare Workers Logs ship structured console.log JSON to Grafana Loki for metrics and observability
• Log Retention. IP addresses hashed immediately at ingestion (never stored raw); audit log retention configured at 90 days (AUDIT_LOG_RETENTION_DAYS in wrangler.toml); critical security event logs are retained for up to 365 days
• Cloudflare Dashboard. Service health monitoring

Status: ✅ Documented - Monitoring strategy defined, Cloudflare Workers Logs and Grafana Loki wired in [observability.logs] blocks across services

Gap: No evidence of specific monitoring dashboards, alerting thresholds, or SIEM integration

5. DDoS Protection

Evidence Source: src/content/trust/security/risk-methodology.mdx (lines 112, 401)

DDoS Protection Evidence:

External Threats:
- DDoS attacks on Cloudflare Workers

Cloud-Native Risks - Advantages:
- Enterprise-grade DDoS protection

Cloudflare DDoS Protection (implicit):

• Platform-level. All Cloudflare Workers benefit from Cloudflare’s global DDoS mitigation
• Automatic. No configuration required
• Scale. Cloudflare handles some of the largest DDoS attacks globally
• Edge distribution. Traffic distributed across 300+ PoPs

Application-Level Protection:

• Rate Limiting. Implemented in APIs (per evidence mapping document)
• Challenge-based. Challenge/response flow adds friction for automated attacks

Status: ✅ Implemented - DDoS protection through Cloudflare platform

Gap: No documentation of DDoS incident response procedures specific to this attack vector

6. Geographic Distribution

Evidence Source: src/content/trust/security/isms-scope.mdx (line 93), src/content/trust/security/business-continuity.mdx

Edge Deployment:

Service Delivery: Global (Cloudflare edge network spans 300+ cities worldwide)

Geographic Distribution Benefits (from Business Continuity Plan, lines 100-131):

Scenario 1: Cloudflare Regional Outage

Likelihood: Low (Cloudflare has >300 PoPs globally)
Impact: Medium (automatic failover to other regions)

Recovery (automatic):
- Cloudflare Workers automatically failover to healthy regions
- Durable Objects migrate to available locations
- No manual intervention required in most cases

Availability Through Distribution:

• 300+ locations. Code deployed globally
• Automatic failover. Regional outages don’t affect global availability
• Low latency. Users connect to nearest edge location
• No single point of failure. Distributed architecture

Status: ✅ Implemented - Geographic distribution through Cloudflare Workers edge deployment

Evidence Quality: Strong - multiple references to global edge deployment

7. Environment Separation

Evidence Source: Multiple references across documentation

Environment Strategy (inferred from documentation):

Based on standard Cloudflare Workers practices and references in docs:

• Production. Production environment (pre-launch) (verify.provii.app, issuer.provii.app)
• Staging. Pre-production testing (referenced in testing guides)
• Development. Local development environments

Separation Mechanisms:

• Cloudflare environments. Separate Workers environments via wrangler.toml
• KV namespaces. Separate namespaces per environment
• Durable Objects. Environment-specific Durable Object instances
• Secrets. Environment-specific secrets in Cloudflare

From Business Continuity (line 47):

Dependencies:
- Cloudflare Workers platform
- Cloudflare KV (CONFIG, BANS)
- Cloudflare KV (CHALLENGES, NONCES namespaces)

Status: 📋 Planned/Partially Implemented - Standard practice assumed, but not explicitly documented

Gap: No explicit documentation of environment separation strategy in ISMS docs

8. Secrets Management

Evidence Source: src/content/trust/security/asset-management.md, src/content/trust/security/business-continuity.mdx

Secret Categories (from Asset Management, lines 15-27):

Level: Restricted (Highest sensitivity)
- Signing keys
- HMAC secrets
Handling: Cloudflare KV only, strict access

Level: Confidential
- API tokens
- Internal docs
Handling: Password managers, team-only access

Signing Key Storage (from Business Continuity, lines 548-553):

Signing Keys:
- Location: Cloudflare KV (primary), offline backup (secondary, encrypted)
- Frequency: At generation, after rotation
- Retention: Until rotated + 1 year
- Recovery: Restore from offline backup

Secret Management Practices:

• Cloudflare KV. Restricted assets stored in KV (encrypted at rest by Cloudflare)
• No hardcoded secrets. Confirmed in Service Account Management (UC-134)
• Environment variables. Cloudflare environment variables for secrets
• Offline backups. Encrypted offline backups for critical keys
• Access control. Strict access controls on Cloudflare account

Key Rotation (from Business Continuity, lines 177-205):

Scenario 3: Signing Key Compromise

Response:
1. Immediate (< 15 min): Revoke compromised key (transition to Disabled status in KV), update JWKS
2. Short-term (< 1 hour): Generate new key pair, update JWKS
3. Communication (< 2 hours): Notify relying parties, publish advisory
4. Recovery (< 24 hours): Monitor for fraudulent credentials

Prevention: Keys stored in Cloudflare Workers secrets; HSM may be evaluated as key management requirements grow

Status: ✅ Implemented - Secrets in Cloudflare Workers secrets, rotation procedures defined

Gap: HSM may be evaluated when key management requirements grow

9. CDN Configuration

Evidence Source: src/content/trust/security/isms-scope.mdx, multiple references

CDN Usage:

Cloudflare Services:
- Workers Assets (CDN for static assets)

Infrastructure:
- Static site infrastructure (Cloudflare Workers Assets)

CDN Applications:

• Static assets. Documentation, JavaScript SDKs
• JWKS hosting. Verification keys for issuers
• Integration examples. Sample code, demos

CDN Security Features (Cloudflare implicit):

• SRI (Subresource Integrity). Mentioned in releases.mdx (line 93)
• TLS. All CDN content served over HTTPS
• Cache control. Configured per asset type
• Edge caching. Content cached at 300+ locations

From Developer Documentation:

guides/sandbox-verifier.mdx (line 249):
import { AgeGate } from 'https://cdn.provii.app/sdk/provii-agegate/v0.1.1/agegate.browser.js';

developers/releases.mdx (line 93):
- SRI hash for CDN integrity

Status: ✅ Implemented - Static sites via Cloudflare Workers Assets and SRI-pinned CDN (cdn.provii.app)

Evidence Quality: Moderate - referenced in guides, but no detailed CDN configuration documented

10. Deployment Architecture

Evidence Source: src/content/trust/security/business-continuity.mdx, src/content/trust/security/isms-scope.mdx

Deployment Infrastructure (from ISMS Scope, lines 67-77):

GitHub:
- Source code repositories
- CI/CD workflows (GitHub Actions)
- Release artifact hosting
- Issue and project management

Build & Release Infrastructure:
- GitHub-hosted runners (ephemeral build environments)
- Sigstore services (Fulcio, Rekor) for artifact signing
- npm registry (JavaScript package distribution)

Deployment Process (from Business Continuity, lines 334-356):

Manual Redeployment:

# Ensure you have latest code
git checkout main
git pull

# Navigate to service directory
cd provii-verifier  # or provii-issuer

# Deploy with wrangler
wrangler deploy --env production

# Verify deployment
curl https://verify.provii.app/health

Prerequisites:
- Cloudflare API token with Workers deployment permissions
- wrangler CLI installed locally
- Access to source code repository

CI/CD Automation (inferred):

• GitHub Actions. Automated workflows for build, test, deploy
• Artefact signing. SLSA Level 3 supply chain security (referenced)
• Hermetic builds. Tamper-proof builds
• Automated deployment. Push to main triggers deployment

Deployment Targets:

• provii-verifier. https://verify.provii.app (Cloudflare Worker)
• provii-issuer. https://issuer.provii.app (Cloudflare Worker)
• Documentation. Astro 5.0 on Cloudflare Workers (docs.provii.app)
• Mobile apps. App Store / Google Play

Status: ✅ Implemented - GitHub Actions CI/CD with manual deployment capability

Gap: No access to actual GitHub Actions workflow files in this repository

Infrastructure Control Mapping

Controls from Evidence Mapping Document

Based on src/content/trust/compliance/requirements/evidence-mapping.md (lines 213-228):

Infrastructure Controls (17 controls):

1. Cloud Architecture ✅ - Documented in ISMS scope
2. Data Residency ✅ - Addressed through privacy-by-design
3. Network Security ✅ - TLS, HMAC, zero trust
4. Infrastructure Monitoring ✅ - Strategy defined, Workers Logs shipped to Grafana Loki
5. DDoS Protection ✅ - Cloudflare platform
6. Geographic Distribution ✅ - 300+ edge locations
7. CDN Configuration ✅ - Cloudflare Workers Assets
8. Network Segmentation 🔄 - Implicit through environment separation
9. Environment Separation 🔄 - Standard practice, not explicitly documented
10. Infrastructure as Code ❌ - No access to IaC files in this repo
11. Deployment Automation ✅ - GitHub Actions (referenced)
12. Secrets Management ✅ - Cloudflare KV, rotation procedures
13. High Availability ✅ - Edge distribution, automatic failover
14. Disaster Recovery ✅ - BCP documented with RTOs/RPOs
15. Backup Procedures ✅ - Documented in BCP
16. Capacity Planning 📋 - Implicit in serverless auto-scaling
17. Compliance & Auditing ✅ - ISMS documentation, audit trails

Cross-References to Other Evidence

Related Evidence

1. API Security:

• HMAC authentication implementation
• Rate limiting (DDoS mitigation)
• API key management
• TLS enforcement

2. Access Control:

• GitHub access controls (branch protection, CODEOWNERS)
• Cloudflare account access management
• Secrets access controls

3. Logging and Monitoring:

• Cloudflare Workers Logs and Grafana Loki configuration
• Log retention (IP hashing at ingestion, audit logs at 90 days; critical security event logs up to 365 days)
• Audit trail coverage

4. Business Continuity:

• RTO/RPO targets
• Disaster recovery procedures
• Backup strategies
• Failover mechanisms

5. Development Practices:

• GitHub Actions CI/CD pipelines
• Deployment automation
• SLSA Level 3 supply chain security

Gaps and Recommendations

Critical Gaps

No critical gaps identified at this time. The identified critical infrastructure controls have documented evidence or are expected to be inherently provided by the Cloudflare platform.

High Priority Gaps

1. Infrastructure as Code Access ❌

• Gap. No access to wrangler.toml, Terraform, or other IaC files
• Location. Application repositories (provii-verifier, provii-issuer, etc.)
• Recommendation. Include IaC files in future evidence gathering from application repos

2. Environment Separation Documentation 🔄

• Gap. No explicit documentation of dev/staging/prod separation strategy
• Evidence. Standard Cloudflare Workers practice, but not documented in ISMS
• Recommendation. Document environment separation strategy in ISMS

3. HSM for Signing Keys 🔄

• Gap. Signing keys in Cloudflare Workers secrets, not HSM
• Status. Deferred. will evaluate when key management requirements grow
• Recommendation. Monitor cloud HSM options; current Cloudflare secrets adequate for scale

Medium Priority Gaps

4. Monitoring Dashboard Documentation 🔄

• Gap. No evidence of specific monitoring dashboards or alerting configuration
• Evidence. Strategy defined, but implementation details not documented
• Recommendation. Document monitoring setup (Grafana Loki dashboards, alerting)

5. DDoS Incident Response 📋

• Gap. No specific DDoS incident response procedures
• Evidence. General incident response procedures exist
• Recommendation. Add DDoS-specific playbook to incident response documentation

6. Regional Compliance Mapping 📋

• Gap. No documentation of Cloudflare data centre locations by region
• Impact. May be needed for jurisdiction-specific compliance
• Recommendation. Document Cloudflare data residency options if needed for compliance

Low Priority Gaps

7. Network Diagrams 📋

• Gap. No visual network architecture diagrams
• Impact. Would improve clarity of security boundaries
• Recommendation. Create infrastructure architecture diagrams for ISMS

8. Capacity Planning 📋

• Gap. No explicit capacity planning documentation
• Mitigation. Serverless architecture auto-scales
• Recommendation. Document scaling limits and capacity monitoring

Recommendations for Standard-Specific Mapping

ISO 27001:2022 Annex A

Applicable Controls:

• A.8.9. Configuration management - wrangler.toml, KV configuration
• A.8.7. Protection against malware - Edge Workers isolation
• A.5.23. Information security for use of cloud services - Cloudflare dependency
• A.8.31. Separation of development, testing, and operational environments - Environment separation

Evidence Location: ISMS scope, business continuity plan

SOC 2 Trust Service Criteria

Availability (A1.2):

• Geographic distribution (300+ PoPs)
• Automatic failover
• RTO/RPO targets
• Business continuity plan

Processing Integrity (PI1.4):

• Secrets management
• Environment separation
• Deployment controls

Confidentiality (C1.1):

• Signing keys in KV
• HMAC secrets management
• Access controls

CSA Cloud Controls Matrix (CCM)

IVS-02: Network Security:

• TLS everywhere
• Zero trust architecture
• Cloudflare WAF

IVS-06: Infrastructure & Virtualization Security:

• Cloudflare Workers isolation
• Edge compute security
• No shared tenancy concerns

IVS-13: Availability:

• Geographic distribution
• DDoS protection
• High availability architecture

NIST Cybersecurity Framework

Protect (PR.IP-3): Configuration change control

• wrangler.toml version control
• Environment-specific configurations
• Infrastructure as code

Protect (PR.DS-6): Integrity checking

• SLSA Level 3 artefact verification
• Signed deployments
• Cloudflare integrity checks

Recover (RC.RP-1): Recovery plan execution

• Business continuity plan
• RTO/RPO targets
• Documented recovery procedures

Evidence Quality Assessment

Strengths

1. ISMS Documentation: Well-documented security policies, procedures, and business continuity plans
2. Clear Architecture: Cloudflare Workers architecture clearly defined and understood
3. Privacy-by-Design: Zero knowledge architecture fundamentally addresses data residency concerns
4. Platform Security: Uses Cloudflare’s enterprise-grade security features
5. Business Continuity: Detailed BCP with scenario planning and RTOs/RPOs

Limitations

1. Documentation-Only Repository: This repository contains ISMS docs, not application code
2. No IaC Files: Actual infrastructure configuration files in separate repositories
3. Inferred Practices: Some controls inferred from standard Cloudflare Workers practices
4. Limited Monitoring Evidence: Monitoring strategy defined but implementation details not documented

Confidence Levels

Next Steps

For Complete Evidence Collection

1. Access Application Repositories: Examine actual infrastructure code in:

• provii-verifier/wrangler.toml
• provii-issuer/wrangler.toml
• .github/workflows/*.yml files
• Terraform/infrastructure code (if exists)

2. Document Environment Separation: Create explicit documentation of dev/staging/prod strategy

3. Create Infrastructure Diagrams: Visual representation of architecture and security boundaries

4. Document Monitoring Implementation: Specific dashboards, alerts, and thresholds

5. HSM Evaluation: Monitor cloud HSM options for when key management requirements grow

For Standard-Specific Documents

This infrastructure evidence can support:

• ISO 27001:2022 Statement of Applicability (Annex A controls)
• SOC 2 Trust Service Criteria (Availability, Processing Integrity, Confidentiality)
• CSA STAR Level 1 Self-Assessment (IVS domain)
• NIST Cybersecurity Framework (Protect and Recover functions)
• Privacy-by-Design assessment (infrastructure supports privacy)

Appendix: File References

Primary Evidence Sources

1. src/content/trust/security/isms-scope.mdx

• Lines 56-77: Infrastructure Scope
• Lines 89-99: Geographic Scope
• Lines 206-213: Security Boundaries

2. src/content/trust/security/business-continuity.mdx

• Lines 30-86: Business Impact Analysis (RTOs/RPOs)
• Lines 98-248: Disaster Scenarios
• Lines 334-394: Recovery Procedures
• Lines 529-561: Backup Procedures

3. src/content/trust/security/risk-methodology.mdx

• Lines 66-74: Infrastructure Assets
• Lines 111-117: Infrastructure Threats
• Lines 312-343: Monitoring and Review
• Lines 395-407: Cloud-Native Risks

4. src/content/trust/security/asset-management.md

• Lines 15-27: Asset Classification
• Lines 33-51: Asset Categories

5. src/content/trust/compliance/requirements/evidence-mapping.md

• Lines 196-229: Infrastructure Evidence Scope

Secondary References

• System components overview

• Repository map

• Lines 141-145: Technology stack

• Lines 102: Infrastructure evidence mission

8. Multiple guides mentioning Cloudflare, CDN, edge deployment:

• guides/sandbox-verifier.mdx
• guides/verifier-quickstart.mdx
• developers/releases.mdx

Document Metadata

• Author. Maelstrom AI
• Evidence Collection Date. 2026-02-14
• Repository. provii-docs/src/content/trust/
• Total Files Examined. 30+ files
• Primary Evidence Documents. 5
• Controls Assessed. 17 infrastructure controls
• Overall Status. ✅ Documented (with gaps requiring application repo access)
• Confidence. Medium-High (excellent ISMS docs, but no access to IaC files)

End of Infrastructure Evidence Report