EN-304-617_v0.0.6.md

**Pass Criteria**: Cryptographic integrity verification AND comprehensive data coverage AND continuous/high-frequency monitoring AND immutable audit trails AND real-time detection AND automated alerts AND incident response integration AND protected monitoring infrastructure AND user/admin notifications AND documentation complete

**Fail Criteria**: No cryptographic verification OR limited data coverage OR infrequent monitoring OR mutable audit trails OR delayed detection OR no alerts OR no incident response OR unprotected monitoring OR incomplete coverage OR no notifications OR incomplete documentation

**Evidence**: Integrity monitoring implementation code review, cryptographic verification testing, data coverage assessment, monitoring frequency configuration, immutable audit trail verification, detection latency measurement, alert generation testing, incident response integration documentation, monitoring infrastructure security review, notification system testing

**References**:

- File Integrity Monitoring: https://csrc.nist.gov/glossary/term/file_integrity_monitoring
- Tamper Detection: https://www.iso.org/standard/56328.html
- Merkle Trees: https://nakamoto.com/merkle-trees/

### Assessment: RDPS-REQ-38 (RDPS security event logging with SIEM integration)

**Reference**: RDPS-REQ-38 - Browser shall provide RDPS security event logging with SIEM integration (RDPS-3 requirement)

**Given**: A conformant browser with RDPS-3 capability requiring enterprise-grade security event logging and analysis

**Task**: This assessment verifies that browsers implement comprehensive RDPS security event logging with SIEM integration support, standard log formats (CEF, LEEF, JSON, Syslog), encrypted transport protocols, sufficient context per entry, reliable transmission with buffering, configurable verbosity levels, tamper protection, and enterprise configuration capabilities.

**Verification**:

1. Verify comprehensive security event logging for all RDPS operations → Comprehensive security event capture implemented
2. Test that logs capture authentication, authorization, data access, config changes → Authentication, authorization, access, and config events logged
3. Verify each log entry includes sufficient context (timestamp, user, IP, operation, outcome) → Sufficient context in each log entry
4. Test that standard log formats supported (CEF, LEEF, JSON, Syslog) → Standard log formats supported (multiple)
5. Verify standard transport protocols supported (TLS syslog, HTTPS, AMQP, Kafka) → Standard transport protocols supported (encrypted)
6. Test compatibility with major SIEM platforms (Splunk, QRadar, Sentinel, ELK) → Major SIEM platform compatibility verified
7. Verify reliable log transmission with buffering and retry mechanisms → Reliable transmission with buffering and retry
8. Test that log transmission encrypted and authenticated → Encrypted and authenticated log transmission
9. Verify configurable log verbosity levels (minimal, standard, detailed, debug) → Configurable verbosity levels available
10. Test tamper protection through cryptographic signing or immutable storage → Tamper protection implemented with enterprise configuration options

**Pass Criteria**: Comprehensive security event logging AND sufficient context per entry AND standard formats (CEF/LEEF/JSON/Syslog) AND standard protocols (TLS/HTTPS) AND SIEM compatibility AND reliable transmission AND encryption/authentication AND configurable verbosity AND tamper protection AND enterprise configuration AND documentation complete

**Fail Criteria**: Limited event logging OR insufficient context OR proprietary formats only OR insecure protocols OR no SIEM compatibility OR unreliable transmission OR unencrypted logs OR fixed verbosity OR no tamper protection OR no enterprise configuration OR incomplete documentation

**Evidence**: Security event catalog, log format specifications, transport protocol documentation, SIEM compatibility matrix, transmission reliability testing, encryption verification, verbosity configuration testing, tamper protection verification, enterprise configuration options, privacy assessment

**References**:

- SIEM Integration: https://www.splunk.com/en_us/blog/learn/siem-security-information-event-management.html
- Security Logging: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html

### Assessment: RDPS-REQ-39 (Geographic data residency requirements enforcement)

**Reference**: RDPS-REQ-39 - Browser shall enforce geographic data residency requirements when configured (RDPS-3 requirement)

**Given**: A conformant browser with RDPS-3 capability supporting configurable geographic data residency controls for regulatory compliance

**Task**: This assessment verifies that browsers implement geographic data residency enforcement with configurable regional restrictions, regional endpoint selection, cryptographic location verification, unauthorized transfer blocking, compliance monitoring and auditing, user transparency, and handling of edge cases (international travel, VPN, failover scenarios).

**Verification**:

1. Verify configurable geographic data residency options available → Geographic residency configuration options available
2. Test that enterprise administrators can specify allowed geographic regions → Enterprise administrators can specify allowed regions
3. Verify browser selects RDPS endpoints within allowed geographic regions → Regional RDPS endpoint selection implemented
4. Test that data storage respects geographic residency constraints → Data storage respects residency constraints
5. Verify data processing occurs only in allowed geographic regions → Data processing limited to allowed regions
6. Test that unauthorized geographic transfers blocked → Unauthorized transfers blocked
7. Verify cryptographic or attestation-based verification of server location → Cryptographic verification of server location
8. Test monitoring detects unauthorized geographic data flows → Monitoring detects policy violations
9. Verify documentation specifies which data types subject to residency controls → Compliance auditing capabilities available
10. Test that users informed about their data's geographic location → User transparency and control over data location

**Pass Criteria**: Geographic residency configuration AND regional endpoint selection AND storage/processing in allowed regions only AND unauthorized transfer blocking AND cryptographic location verification AND monitoring AND auditing AND user transparency AND edge case handling AND documentation complete

**Fail Criteria**: No residency configuration OR no regional selection OR storage/processing outside allowed regions OR no transfer blocking OR no location verification OR no monitoring OR no auditing OR no user transparency OR poor edge case handling OR incomplete documentation

**Evidence**: Geographic residency configuration documentation, regional endpoint selection testing, storage location verification, processing location verification, unauthorized transfer blocking tests, cryptographic attestation verification, monitoring system testing, compliance audit reports, user interface documentation, edge case handling testing

**References**:

- Cloud Data Location: https://www.microsoft.com/en-us/trust-center/privacy/data-location

### Assessment: RDPS-REQ-40 (Zero-trust architecture for RDPS access)

**Reference**: RDPS-REQ-40 - Browser shall implement zero-trust architecture for RDPS access (RDPS-3 requirement)

**Given**: A conformant browser with RDPS-3 capability implementing zero-trust security principles for remote data processing access

**Task**: This assessment verifies that browsers implement zero-trust architecture for RDPS access with continuous per-request authentication/authorization, multi-factor context-aware identity verification, risk-based access decisions, least-privilege permissions, time-limited grants, anomaly monitoring, network micro-segmentation, and always-encrypted traffic.

**Verification**:

1. Verify continuous authentication and authorization for every RDPS request → Continuous authentication/authorization per request
2. Test that session-based trust not assumed (each request independently verified) → No session-based trust assumed
3. Verify multi-factor authentication required for RDPS access → Multi-factor authentication enforced
4. Test context-aware authentication considers device posture, location, behavior → Context-aware authentication (device, location, behavior)
5. Verify risk scoring aggregates multiple factors for access decisions → Risk-based access decisions
6. Test least-privilege access with fine-grained resource permissions → Least-privilege fine-grained permissions
7. Verify time-limited access grants expire and require renewal → Time-limited access grants
8. Test continuous monitoring detects access pattern anomalies → Anomaly detection and monitoring
9. Verify network micro-segmentation isolates RDPS components → Network micro-segmentation implemented
10. Test end-to-end encryption regardless of network location → End-to-end encryption always enforced

**Pass Criteria**: Continuous verification per request AND no session-based trust AND multi-factor authentication AND context-aware authentication AND risk-based decisions AND least-privilege AND time-limited grants AND anomaly monitoring AND micro-segmentation AND always-encrypted AND documentation complete

**Fail Criteria**: Session-based trust OR single-factor authentication OR no context awareness OR no risk scoring OR broad privileges OR indefinite grants OR no anomaly monitoring OR no segmentation OR conditional encryption OR incomplete documentation

**Evidence**: Zero-trust architecture design documentation, per-request verification testing, multi-factor authentication verification, context-aware authentication testing, risk scoring implementation review, permission granularity assessment, access grant expiration testing, anomaly detection verification, network segmentation documentation, encryption verification across all scenarios

**References**:

- Zero Trust Architecture: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
- Zero Trust Principles: https://www.microsoft.com/en-us/security/business/zero-trust
- Continuous Verification: https://www.cisa.gov/zero-trust-maturity-model

### Assessment: RDPS-REQ-41 (Regulatory compliance logging for RDPS operations)

**Reference**: RDPS-REQ-41 - Browser shall support regulatory compliance logging for RDPS operations (RDPS-3 requirement)

**Given**: A conformant browser with RDPS-3 capability requiring compliance with regulatory audit and logging requirements

**Task**: This assessment verifies that browsers implement regulatory compliance logging for RDPS operations capturing data subject rights, consent, breaches, transfers, retention, and administrative actions with regulatory-required fields, immutable storage, regulation-specific retention periods (1-7 years), compliance reporting templates, and enterprise policy configuration.

**Verification**:

1. Verify compliance logging captures data subject rights exercises (GDPR Article 15-22) → Data subject rights exercises logged (access, erasure, portability, etc.)
2. Test that consent and withdrawal events logged with legal basis → Consent and legal basis tracked
3. Verify data breach detection and notification events logged → Breach detection and notification logged
4. Test that cross-border transfer events logged with legal mechanism → Cross-border transfers logged with legal mechanism
5. Verify data retention and deletion operations logged → Retention and deletion operations logged
6. Test that administrative access to sensitive data logged → Administrative access logged
7. Verify security control changes logged (encryption, access controls) → Regulatory-required fields in each entry
8. Test that each log entry includes regulatory-required fields → Immutable log storage implemented
9. Verify log immutability through append-only storage or cryptographic chaining → Regulation-specific retention periods enforced
10. Test that logs retained for regulation-specific periods (1-7 years typical) → Compliance reporting with templates and export capabilities

**Pass Criteria**: All regulatory events logged (rights, consent, breaches, transfers, retention) AND regulatory-required fields AND immutable storage AND regulation-specific retention AND compliance reporting AND export capabilities AND enterprise configuration AND documentation complete

**Fail Criteria**: Missing regulatory events OR insufficient fields OR mutable logs OR non-compliant retention OR no reporting OR no export OR no enterprise configuration OR incomplete documentation

**Evidence**: Compliance event catalog mapped to regulations, log schema with regulatory fields, immutability verification (append-only storage, cryptographic chaining), retention policy documentation, compliance report templates, export format specifications, enterprise configuration options, regulatory mapping documentation

**References**:

- GDPR Compliance Logging: https://gdpr.eu/
- ISO 27001 Audit Controls: https://www.iso.org/standard/27001

### Assessment: RDPS-REQ-42 (Automated RDPS security scanning and vulnerability detection)

**Reference**: RDPS-REQ-42 - Browser shall implement automated RDPS security scanning and vulnerability detection (RDPS-3 requirement)

**Given**: A conformant browser with RDPS-3 capability requiring continuous security assessment of remote data processing infrastructure

**Task**: This assessment verifies that browsers implement automated RDPS security scanning covering vulnerability, configuration, dependency, and compliance domains with regular or event-triggered execution, vulnerability management workflow integration, automated prioritization, critical alerts (CVSS 9.0+), security dashboards, and remediation tracking.

**Verification**:

1. Verify automated vulnerability scanning for RDPS infrastructure components → Automated vulnerability scanning implemented
2. Test that vulnerability scanning identifies known CVEs in OS, applications, libraries → Configuration scanning for insecure settings
3. Verify configuration scanning detects insecure settings and weak crypto → Dependency scanning for supply chain risks
4. Test that dependency scanning identifies vulnerable third-party libraries → Compliance scanning (CIS, ISO 27001)
5. Verify compliance scanning checks adherence to security frameworks (CIS, ISO 27001) → Regular scanning schedule (daily/weekly) or event-triggered
6. Test that scanning performed regularly (daily/weekly) or event-triggered → Vulnerability management workflow integration
7. Verify scanning results integrated with vulnerability management workflows → Automated prioritization by severity and exploitability
8. Test automated prioritization based on severity (CVSS scores) and exploitability → Critical vulnerability immediate alerting
9. Verify critical vulnerabilities (CVSS 9.0+) trigger immediate alerts → Security dashboards with trends and metrics
10. Test that security dashboards show trends, metrics, compliance, and risk scores → False positive management and remediation tracking

**Pass Criteria**: Multi-domain scanning (vulnerability, config, dependency, compliance) AND regular/event-triggered scanning AND vulnerability management integration AND automated prioritization AND critical alerts AND security dashboards AND remediation tracking AND false positive management AND documentation complete

**Fail Criteria**: Single-domain scanning only OR infrequent scanning OR no workflow integration OR manual prioritization OR no critical alerts OR no dashboards OR no tracking OR poor false positive handling OR incomplete documentation

**Evidence**: Security scanning tool documentation, vulnerability scan reports, configuration scan results, dependency scan output, compliance scan reports, scanning frequency configuration, vulnerability management workflow documentation, prioritization algorithm, critical alert examples, security dashboard screenshots, remediation tracking reports

**References**:

- Vulnerability Scanning: https://nvd.nist.gov/vuln/search
- CIS Benchmarks: https://www.cisecurity.org/cis-benchmarks/
- OWASP Dependency Check: https://owasp.org/www-project-dependency-check/

### Assessment: RDPS-REQ-43 (Cryptographic proof of RDPS data integrity)

**Reference**: RDPS-REQ-43 - Browser shall provide cryptographic proof of RDPS data integrity (RDPS-3 requirement)

**Given**: A conformant browser with RDPS-3 capability requiring verifiable proof of data integrity for critical remote processing

**Task**: This assessment verifies that browsers implement cryptographic proof mechanisms for RDPS data integrity (signatures, HMAC, Merkle trees, authenticated encryption) with immediate proof generation, tamper-evident storage, efficient verification, batch support, audit trails, third-party verification capability, and user-initiated on-demand verification with proof downloads.

**Verification**:

1. Verify cryptographic integrity mechanisms implemented (signatures, HMAC, Merkle trees, authenticated encryption) → Cryptographic integrity mechanisms implemented (multiple types)
2. Test that integrity proofs generated immediately upon data creation/modification → Proofs generated immediately upon creation/modification
3. Verify proofs stored securely in tamper-evident storage → Tamper-evident proof storage
4. Test that verification possible at any time by authorized parties → Verification available at any time
5. Verify verification process efficient for regular checking (hourly/daily) → Efficient verification for regular checking
6. Test batch verification of multiple data items supported → Batch verification supported
7. Verify clear verification results provided (verified, tampered, unable to verify) → Clear verification results
8. Test that audit trail maintained for all verification events → Verification audit trail maintained
9. Verify third-party verification supported (transparency logs, notarization) → Third-party verification capability
10. Test that users can initiate on-demand verification and download proofs → User on-demand verification and proof download

**Pass Criteria**: Multiple cryptographic mechanisms AND immediate proof generation AND tamper-evident storage AND any-time verification AND efficient regular checking AND batch verification AND clear results AND audit trail AND third-party verification AND user controls AND documentation complete

**Fail Criteria**: Single mechanism only OR delayed proof generation OR insecure storage OR limited verification access OR inefficient verification OR no batch support OR unclear results OR no audit trail OR no third-party verification OR no user controls OR incomplete documentation

**Evidence**: Cryptographic mechanism implementation documentation, proof generation verification, tamper-evident storage testing, verification access control testing, performance benchmarks for verification, batch verification testing, verification result examples, audit trail documentation, third-party verification testing, user interface documentation

**References**:

- Digital Signatures: https://csrc.nist.gov/projects/digital-signatures
- Merkle Trees: https://nakamoto.com/merkle-trees/
- Certificate Transparency: https://certificate.transparency.dev/

### Assessment: RDPS-REQ-44 (Secure multi-tenancy with data isolation in RDPS)

**Reference**: RDPS-REQ-44 - Browser shall implement secure multi-tenancy with data isolation in RDPS (RDPS-3 requirement)

**Given**: A conformant browser with RDPS-3 capability serving multiple independent users or organizations through shared infrastructure

**Task**: This assessment verifies that browsers implement secure RDPS multi-tenancy with per-tenant encryption keys, data-layer access controls, separate database schemas, query filtering, resource quotas, process/container isolation, network isolation, identity boundaries, separate audit logs and backups, resilience against side-channel attacks, and penetration testing of tenant boundaries.

**Verification**:

1. Verify per-tenant encryption keys prevent cross-tenant data decryption → Per-tenant encryption keys implemented
2. Test that per-tenant access controls enforced at data layer → Data-layer access control enforcement
3. Verify per-tenant database schemas or namespaces implemented → Separate database schemas or namespaces
4. Test that query results never include cross-tenant data → Query result filtering prevents cross-tenant data
5. Verify per-tenant resource quotas (storage, compute, bandwidth, rate limits) → Resource quotas enforced per tenant
6. Test process or container isolation with separate execution contexts → Process/container isolation per tenant
7. Verify network isolation prevents cross-tenant communication → Network isolation between tenants
8. Test strict tenant boundaries in identity and authentication systems → Identity system tenant boundary enforcement
9. Verify separate audit logs per tenant with no cross-tenant access → Separate audit logs per tenant
10. Test separate backup and recovery per tenant → Tenant-specific backup/recovery and configuration

**Pass Criteria**: Per-tenant encryption AND data-layer access controls AND separate schemas AND query filtering AND resource quotas AND process isolation AND network isolation AND identity boundaries AND separate audit logs AND separate backup/recovery AND penetration testing AND documentation complete

**Fail Criteria**: Shared encryption OR inadequate access controls OR shared schemas OR cross-tenant queries OR no quotas OR shared processes OR no network isolation OR weak identity boundaries OR shared logs OR shared backups OR no penetration testing OR incomplete documentation

**Evidence**: Multi-tenancy architecture documentation, per-tenant encryption verification, access control testing, database schema isolation verification, query filtering tests, resource quota enforcement testing, process isolation verification, network isolation testing, identity boundary testing, audit log separation verification, backup/recovery isolation testing, penetration test reports

**References**:

- Multi-Tenancy Security: https://csrc.nist.gov/publications/detail/sp/800-144/final
- Cloud Isolation: https://aws.amazon.com/compliance/data-privacy-faq/
- Tenant Isolation Patterns: https://docs.microsoft.com/en-us/azure/architecture/guide/multitenant/considerations/tenancy-models

### Assessment: RDPS-REQ-45 (RDPS security incident response procedures)

**Reference**: RDPS-REQ-45 - Browser shall provide incident response procedures for RDPS breaches (RDPS-3 requirement)

**Given**: A conformant browser with RDPS-3 capability requiring documented incident response capabilities for security breaches

**Task**: This assessment verifies that browsers have documented and tested RDPS incident response procedures following established frameworks (NIST, SANS, ISO 27035) with incident classification, RDPS-specific scenarios, 24/7 capability, automated detection/alerting, incident tracking systems, regular drills (annual minimum), post-incident analysis, and regulatory-compliant user notification.

**Verification**:

1. Verify comprehensive incident response procedures documented following established frameworks → Comprehensive IR procedures documented (NIST, SANS, ISO frameworks)
2. Test incident classification criteria and escalation procedures defined → Incident classification and escalation procedures defined
3. Verify containment, investigation, remediation, and recovery procedures documented → Containment, investigation, remediation, recovery procedures
4. Test RDPS-specific incident scenarios documented with response procedures → RDPS-specific incident scenarios with response plans
5. Verify 24/7 incident response capability with on-call security team → 24/7 incident response capability
6. Test automated incident detection and alerting integrated with monitoring → Automated detection and alerting
7. Verify incident tracking and management system implemented → Incident tracking system
8. Test regular incident response drills performed (minimum annually) → Regular IR drills and exercises (annual minimum)
9. Verify post-incident lessons learned and root cause analysis documented → Post-incident analysis and improvements
10. Test that users notified of incidents according to regulatory timelines → User notification within regulatory timelines

**Pass Criteria**: Comprehensive documented procedures following frameworks AND incident classification AND RDPS-specific scenarios AND 24/7 capability AND automated detection AND tracking system AND regular drills (annual minimum) AND post-incident analysis AND regulatory-compliant user notification AND documentation complete

**Fail Criteria**: No documented procedures OR no classification OR generic scenarios only OR no 24/7 capability OR manual detection OR no tracking OR no drills OR no post-incident analysis OR delayed/missing user notification OR incomplete documentation

**Evidence**: Incident response procedure documentation, incident classification matrix, RDPS scenario playbooks, on-call schedule documentation, incident detection system configuration, incident tracking system, drill schedules and reports, post-incident review documentation, user notification templates and timelines, regulatory compliance verification

**References**:

- NIST Incident Response: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf
- SANS Incident Response: https://www.sans.org/white-papers/33901/

### Assessment: RDPS-REQ-46 (RDPS access revocation mechanisms)

**Reference**: RDPS-REQ-46 - Browser shall implement RDPS access revocation mechanisms (RDPS-3 requirement)

**Given**: A conformant browser with RDPS-3 capability requiring rapid access revocation for compromised accounts or terminated users

**Task**: This assessment verifies that browsers implement rapid RDPS access revocation mechanisms (tokens, credentials, devices, accounts) with immediate effectiveness (seconds to minutes) across all components, prevention of cached bypass, individual and bulk revocation, multi-channel administrative interfaces, audit trails, automated security-triggered revocation, and user notification.

**Verification**:

1. Verify multiple revocation mechanisms implemented (tokens, credentials, devices, accounts) → Multiple revocation mechanisms at different layers
2. Test that revocation effective within seconds to minutes across all RDPS components → Immediate revocation (seconds to minutes) across all components
3. Verify revoked access cannot be restored through cached credentials or stale state → Prevention of cached credential bypass
4. Test individual and bulk revocation capabilities → Individual and bulk revocation supported
5. Verify administrative interfaces enable revocation through multiple channels → Multi-channel administrative revocation interfaces
6. Test revocation effectiveness verification mechanisms → Revocation effectiveness verification
7. Verify audit trails maintained for all revocation events → Comprehensive revocation audit trails
8. Test automated revocation triggers respond to security events → Automated security-event-triggered revocation
9. Verify user notification of revocation (when appropriate) → User notification (when appropriate)
10. Test enterprise administrator configuration of revocation policies → Enterprise policy configuration and reporting

**Pass Criteria**: Multiple revocation mechanisms AND immediate effectiveness (seconds to minutes) AND no cached bypass AND individual/bulk revocation AND multi-channel interfaces AND effectiveness verification AND audit trails AND automated triggers AND user notification AND enterprise policies AND documentation complete

**Fail Criteria**: Single mechanism only OR delayed revocation OR cached bypass possible OR limited revocation scope OR single channel only OR no verification OR no audit trails OR no automation OR no user notification OR no enterprise policies OR incomplete documentation

**Evidence**: Revocation mechanism documentation, revocation latency measurements across all components, cached credential bypass testing, bulk revocation testing, administrative interface documentation, effectiveness verification testing, audit trail examples, automated trigger configuration, user notification templates, enterprise policy documentation

**References**:

- OAuth Token Revocation: https://datatracker.ietf.org/doc/html/rfc7009

### Assessment: RDPS-REQ-47 (RDPS transparency reporting for data access)

**Reference**: RDPS-REQ-47 - Browser shall provide transparency reporting for RDPS data access (RDPS-3 requirement)

**Given**: A conformant browser with RDPS-3 capability requiring transparent reporting of data access for user trust and regulatory compliance

**Task**: This assessment verifies that browsers provide RDPS transparency reporting showing all data access types (client, administrative, third-party, automated) with sufficient entry detail, on-demand user access, standard format downloads (PDF, CSV, JSON), user-configurable notifications, government request reporting (where legal), enterprise aggregate reporting, and 1-year minimum retention with tampering protection.

**Verification**:

1. Verify user-facing transparency interfaces showing all RDPS data access → User-facing transparency interfaces implemented
2. Test that reports include browser client, administrative, third-party, and automated access → Comprehensive access coverage (client, admin, third-party, automated)
3. Verify each entry includes timestamp, accessor, type, data categories, justification, duration → Sufficient detail in each report entry (timestamp, accessor, type, categories, justification)
4. Test that users can access transparency reports on demand → On-demand user access to reports
5. Verify download capabilities in standard formats (PDF, CSV, JSON) → Standard format downloads available
6. Test user-configurable notifications for specific access types → User-configurable access notifications
7. Verify government data request transparency reporting (where legally permissible) → Government request transparency (where legal)
8. Test enterprise aggregate access reporting with anomaly identification → Enterprise aggregate reporting with anomaly detection
9. Verify balance between transparency and security (no security mechanism disclosure) → Security and privacy balanced appropriately
10. Test efficient report generation with minimal performance impact → Reports retained for minimum 1 year with tampering protection

**Pass Criteria**: Comprehensive transparency interfaces AND all access types covered AND sufficient entry detail AND on-demand access AND standard format downloads AND user notifications AND government request reporting (where legal) AND enterprise reporting AND appropriate security/privacy balance AND retention (1 year minimum) AND documentation complete

**Fail Criteria**: Limited transparency OR missing access types OR insufficient detail OR no on-demand access OR no downloads OR no notifications OR no government reporting OR no enterprise reporting OR security/privacy imbalance OR short retention OR incomplete documentation

**Evidence**: Transparency interface documentation, access type coverage assessment, report entry examples, user access mechanism testing, download format verification, notification configuration testing, government request reports (if available), enterprise reporting examples, security/privacy review, retention verification, user education materials

**References**:

- GDPR Article 15 Right of Access: https://gdpr.eu/article-15-right-of-access/
- Transparency Reporting: https://www.eff.org/issues/transparency
- Google Transparency Report: https://transparencyreport.google.com/

### Assessment: RDPS-REQ-48 (Forward secrecy for RDPS communications)

**Reference**: RDPS-REQ-48 - Browser shall implement forward secrecy for RDPS communications (RDPS-3 requirement)

**Given**: A conformant browser with RDPS-3 capability requiring forward secrecy protection for remote data processing communications

**Task**: This assessment verifies that browsers implement forward secrecy for all RDPS communications using TLS 1.3 or TLS 1.2 with ECDHE/DHE cipher suites, disable non-forward-secret ciphers (RSA key exchange), verify endpoint support, securely destroy session keys, resist downgrade attacks, and provide enterprise monitoring and policy enforcement.

**Verification**:

1. Verify forward-secret cipher suites implemented for all RDPS communications → Forward-secret cipher suites implemented (ECDHE, DHE)
2. Test TLS 1.3 used (all cipher suites provide forward secrecy) or TLS 1.2 with ECDHE/DHE → TLS 1.3 or TLS 1.2 with FS cipher suites
3. Verify ECDHE prioritized over DHE for performance → ECDHE prioritized for performance
4. Test that non-forward-secret cipher suites (RSA key exchange) disabled → Non-FS cipher suites disabled (RSA key exchange)
5. Verify browser checks RDPS endpoint support for forward-secret ciphers → Endpoint forward secrecy verification
6. Test browser refuses or warns when endpoint lacks forward secrecy support → Connection refusal or prominent warnings for non-FS endpoints
7. Verify cipher suite selection logged for security auditing → Cipher suite selection logging
8. Test key material securely destroyed after session termination → Secure key destruction after sessions
9. Verify resistance to downgrade attacks forcing weaker ciphers → Downgrade attack resistance
10. Test enterprise administrators can verify and monitor cipher suite usage → Enterprise verification, monitoring, and policy enforcement

**Pass Criteria**: Forward-secret cipher suites for all RDPS AND TLS 1.3 or TLS 1.2 with ECDHE/DHE AND ECDHE prioritized AND non-FS disabled AND endpoint verification AND warnings/refusal AND logging AND secure key destruction AND downgrade resistance AND enterprise monitoring AND documentation complete

**Fail Criteria**: Non-FS cipher suites allowed OR no TLS 1.3 and weak TLS 1.2 OR DHE without ECDHE OR RSA key exchange enabled OR no endpoint verification OR silent non-FS acceptance OR no logging OR insecure key handling OR downgrade vulnerable OR no enterprise monitoring OR incomplete documentation

**Evidence**: Cipher suite configuration documentation, TLS connection testing showing FS cipher suites, endpoint verification testing, non-FS endpoint handling tests, cipher suite logging examples, key destruction verification, downgrade attack testing, enterprise monitoring interface documentation

**References**:

- Perfect Forward Secrecy: https://en.wikipedia.org/wiki/Forward_secrecy
- TLS 1.3 Specification: https://datatracker.ietf.org/doc/html/rfc8446
- OWASP TLS Cipher String Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/TLS_Cipher_String_Cheat_Sheet.html

### Assessment: RDPS-REQ-49 (User notification of RDPS security events)

**Reference**: RDPS-REQ-49 - Browser shall provide user notification of RDPS security events (RDPS-3 requirement)

**Given**: A conformant browser with RDPS-3 capability requiring user notification of security-relevant events

**Task**: This assessment verifies that browsers implement comprehensive RDPS security event notifications covering critical events (new device, authentication, data access, config changes, incidents, lifecycle) with multiple delivery channels (in-browser, email, push, SMS), user-configurable preferences, sufficient context, appropriate timing (immediate, near-real-time, digest), intelligent aggregation preventing fatigue, and notification history management.

**Verification**:

1. Verify notifications for critical security events (new device, location, authentication) → Critical security event notifications implemented
2. Test notifications for data access events (administrative access, third-party disclosure) → Data access and configuration change notifications
3. Verify notifications for security configuration changes → Security incident and data lifecycle notifications
4. Test notifications for security incidents and data lifecycle events → Multiple delivery channels with user preferences
5. Verify multiple delivery channels (in-browser, email, mobile push, SMS) → Sufficient context in notifications
6. Test user-configurable notification preferences → Appropriate timing (immediate, near-real-time, digest)
7. Verify sufficient context in each notification (what, when, where, data affected, actions) → Intelligent aggregation preventing notification fatigue
8. Test appropriate notification timing (immediate for critical, near-real-time for important) → Risk-based prioritization highlighting critical events
9. Verify intelligent aggregation and risk-based prioritization prevent fatigue → Notification history and preference management
10. Test notification history review and preference configuration → Enterprise policy configuration respecting user preferences

**Pass Criteria**: Comprehensive security event coverage AND multiple delivery channels AND user-configurable preferences AND sufficient context AND appropriate timing AND intelligent aggregation AND risk prioritization AND notification history AND user preference management AND enterprise policies AND documentation complete

**Fail Criteria**: Limited event coverage OR single channel only OR no user preferences OR insufficient context OR inappropriate timing OR no aggregation (fatigue) OR no prioritization OR no history OR no preference management OR no enterprise policies OR incomplete documentation

**Evidence**: Security event notification catalog, delivery channel documentation, notification preference UI, notification content examples, timing configuration, aggregation and prioritization algorithms, notification history interface, enterprise policy documentation, user education materials

**References**:

- User Notification Design: https://material.io/design/platform-guidance/android-notifications.html

### Assessment: RDPS-REQ-50 (Service discontinuation and data migration documentation)

**Reference**: RDPS-REQ-50 - Browser shall document service discontinuation and data migration procedures (RDPS-3 requirement)

**Given**: A conformant browser with RDPS-3 capability requiring documented procedures for service discontinuation scenarios

**Task**: This assessment verifies that browsers document service discontinuation procedures with minimum notification timelines (90 days consumer, 180 days enterprise), data export in standard formats, migration assistance, transition periods, secure deletion, multiple discontinuation scenarios, anytime data export capability, complete data/metadata export, and enterprise enhanced protections (extended timelines, dedicated support, escrow options).

**Verification**:

1. Verify documented service discontinuation procedures including notification timelines → Service discontinuation procedures documented
2. Test that minimum notification periods specified (90 days consumer, 180 days enterprise) → Minimum notification timelines (90 days consumer, 180+ days enterprise)
3. Verify data export capabilities in standard formats (JSON, XML, CSV, original formats) → Data export in standard open formats
4. Test data migration assistance documentation and tools → Migration assistance documentation and tools
5. Verify service transition period with continued read-only access → Transition period with continued access
6. Test data deletion procedures after termination with secure deletion → Secure data deletion post-termination
7. Verify documentation addresses various discontinuation scenarios → Multiple discontinuation scenarios addressed
8. Test that users can export all their data at any time (not just during discontinuation) → Anytime data export capability
9. Verify export includes all user data and metadata with completeness verification → Complete data and metadata export with verification
10. Test enterprise enhanced protections (longer periods, dedicated support, escrow) → Enterprise enhanced protections (extended timelines, support, escrow options)

**Pass Criteria**: Comprehensive discontinuation documentation AND minimum notification periods (90/180 days) AND data export in standard formats AND migration assistance AND transition period AND secure deletion AND multiple scenarios addressed AND anytime export AND complete data export AND enterprise protections AND documentation complete

**Fail Criteria**: No discontinuation documentation OR insufficient notification periods OR proprietary export formats only OR no migration assistance OR no transition period OR insecure deletion OR single scenario only OR export only during discontinuation OR incomplete export OR no enterprise protections OR incomplete documentation

**Evidence**: Service discontinuation procedure documentation, notification timeline specifications, data export format documentation, migration tool documentation, transition period policies, data deletion procedures, discontinuation scenario documentation, anytime export verification, export completeness testing, enterprise protection agreements, data portability standards participation

**References**:

- GDPR Article 20 Data Portability: https://gdpr.eu/article-20-right-to-data-portability/
- Service Discontinuation Best Practices: https://www.eff.org/deeplinks/2019/10/adversarial-interoperability

### Assessment: RDPS-REQ-51 (Enterprise administrator RDPS security policy configuration)

**Reference**: RDPS-REQ-51 - Enterprise administrators shall be able to configure RDPS security policies (RDPS-3 requirement)

**Given**: A conformant browser with RDPS-3 capability deployed in enterprise environments requiring centralized security policy management

**Task**: This assessment verifies that browsers provide centralized enterprise RDPS policy management for authentication, encryption, data residency, access control, monitoring, incident response, and data lifecycle with immediate enforcement across installations, policy compliance reporting, inheritance/versioning/testing capabilities, tamper prevention, and comprehensive configuration documentation.

**Verification**:

1. Verify centralized policy management interfaces for enterprise administrators → Centralized policy management interfaces available
2. Test authentication policy configuration (MFA, passwords, certificates, biometrics) → Authentication policies configurable (MFA, passwords, certs, biometrics)
3. Verify encryption policy configuration (TLS versions, cipher suites, E2EE, hardware keys) → Encryption policies configurable (TLS, ciphers, E2EE, hardware)
4. Test data residency policy configuration (geographic regions, cross-border controls) → Data residency policies configurable
5. Verify access control policy configuration (data access, admin access, restrictions) → Access control policies configurable
6. Test monitoring and logging policy configuration (verbosity, retention, SIEM, compliance) → Monitoring and logging policies configurable
7. Verify incident response policy configuration (notifications, escalation, automation) → Incident response and data lifecycle policies configurable
8. Test data lifecycle policy configuration (retention, deletion, backup, classification) → Immediate policy enforcement across installations
9. Verify immediate policy enforcement across all installations → Policy compliance dashboards with metrics and violation reporting
10. Test policy compliance reporting and violation prevention → Policy inheritance, versioning, testing, and comprehensive documentation

**Pass Criteria**: Centralized management interfaces AND comprehensive policy categories (authentication, encryption, residency, access, monitoring, incident response, lifecycle) AND immediate enforcement AND compliance reporting AND policy inheritance/versioning AND testing capabilities AND tamper prevention AND documentation complete

**Fail Criteria**: No centralized management OR limited policy categories OR delayed enforcement OR no compliance reporting OR no inheritance/versioning OR no testing OR user tampering possible OR incomplete documentation

**Evidence**: Policy management interface documentation, authentication policy configuration testing, encryption policy testing, data residency policy testing, access control policy testing, monitoring policy testing, policy enforcement verification, compliance dashboard screenshots, policy inheritance testing, versioning and rollback testing, policy template documentation, integration guides

**References**:

- Chrome Enterprise Policies: https://chromeenterprise.google/policies/
- Microsoft Intune: https://docs.microsoft.com/en-us/mem/intune/
- NIST Enterprise Configuration Management: https://csrc.nist.gov/publications/detail/sp/800-70/rev-4/final

### Assessment: RDPS-REQ-52 (Fully offline browser operation without remote connectivity)

**Reference**: RDPS-REQ-52 - Browser shall operate fully offline without requiring remote connectivity (RDPS-0 requirement)

**Given**: A conformant browser claiming RDPS-0 capability (no remote data processing) for air-gapped or offline-only deployments

**Task**: This assessment verifies that browsers operate completely offline with all core functionality (rendering, apps, bookmarks, settings, developer tools, security features), no network connectivity requirements for installation/setup/activation/updates, no error messages or degraded warnings, complete offline installers, and indefinite offline operation capability.

**Verification**:

1. Verify browser installs completely offline using offline installer → Complete offline installation with offline installer
2. Test that initial setup completes without network connectivity → No online activation or registration required
3. Verify all core functionality works offline (rendering, JavaScript, apps, bookmarks, settings) → All core functionality operational offline
4. Test that security features function without network (sandbox, encryption, isolation) → Security features fully functional without network
5. Verify browser never attempts network connections when offline → No network connection attempts when offline
6. Test that no error messages or warnings about missing network → No error messages or degraded functionality warnings
7. Verify offline-capable web applications work correctly (PWAs, service workers) → Offline web application support (PWAs, service workers)
8. Test that browser settings and configuration fully accessible offline → All settings and configuration accessible offline
9. Verify developer tools fully functional offline → Developer tools fully functional offline
10. Test that browser operates indefinitely without updates or online validation → Indefinite offline operation without degradation

**Pass Criteria**: Complete offline installation AND no online activation AND all core functionality offline AND all security features offline AND no network attempts AND no error/warning messages AND offline web app support AND indefinite operation AND documentation complete

**Fail Criteria**: Requires online installation OR online activation required OR limited functionality offline OR security features require network OR network connection attempts OR error/warning messages OR no offline app support OR time-limited offline OR incomplete documentation

**Evidence**: Offline installer verification, offline installation testing, network monitoring showing zero connection attempts, functionality testing without network, security feature verification offline, error message audit, offline web app testing, long-term offline operation testing, documentation review

**References**:

- Offline Web Applications: https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Offline_Service_workers
- Air-Gapped System Security: https://csrc.nist.gov/glossary/term/air_gap
- Offline-First Design: https://offlinefirst.org/

### Assessment: RDPS-REQ-53 (All user data stored locally without remote synchronization)

**Reference**: RDPS-REQ-53 - All user data shall be stored locally without remote synchronization (RDPS-0 requirement)

**Given**: A conformant browser claiming RDPS-0 capability (no remote data processing) for local-only data storage

**Task**: This assessment verifies that browsers store all user data types (history, bookmarks, passwords, autofill, cookies, settings, extensions, cached content) exclusively in local file system locations with no remote endpoints, no synchronization protocols, no sync features, zero network transmission, and documentation clearly stating local-only storage with user backup responsibilities and data portability guidance.

**Verification**:

1. Verify all user data types stored in local file system locations → All user data types stored locally (history, bookmarks, passwords, etc.)
2. Test that browsing history, bookmarks, passwords stored locally only → Local file system storage locations only
3. Verify form autofill, cookies, downloads, search history stored locally → No remote endpoints configured
4. Test that browser settings, extensions, cached content stored locally → No synchronization protocols present
5. Verify offline web app data (service workers, IndexedDB, localStorage) stored locally → No sync account or cloud backup features
6. Test that no remote endpoints configured for any data storage → Zero network transmission of user data (verified via monitoring)
7. Verify no synchronization protocols implemented (no sync code) → Documentation states local-only storage
8. Test that browser provides no remote synchronization features (no sync accounts) → User backup responsibility explained
9. Verify network monitoring shows zero data transmission for user data → Data loss risk warnings provided
10. Test documentation clearly states local-only storage and backup responsibilities → Data portability guidance (manual export/import)

**Pass Criteria**: All user data types local AND local file system storage AND no remote endpoints AND no sync protocols AND no sync features AND zero network transmission AND clear documentation AND backup guidance AND data loss warnings AND portability guidance

**Fail Criteria**: Any remote storage OR remote endpoints configured OR sync protocols present OR sync features available OR network data transmission OR unclear documentation OR no backup guidance OR no warnings OR no portability guidance

**Evidence**: File system analysis showing local-only storage, network monitoring showing zero user data transmission, code review showing no synchronization capabilities, documentation stating local-only storage with backup responsibilities, data portability documentation

**References**:

- Local Storage Privacy: https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
- Air-Gapped Data Management: https://csrc.nist.gov/glossary/term/air_gap

### Assessment: RDPS-REQ-54 (No telemetry, diagnostics, or usage data transmission)

**Reference**: RDPS-REQ-54 - Browser shall not transmit telemetry, diagnostics, or usage data to remote servers (RDPS-0 requirement)

**Given**: A conformant browser claiming RDPS-0 capability (no remote data processing) for privacy-preserving operation

**Task**: This assessment verifies that browsers do not collect or transmit any telemetry, diagnostics, crash reports, usage analytics, or statistical data with no analytics SDKs or libraries, no crash reporting services, zero network transmission, verifiable through network monitoring and code review, and documentation clearly stating no telemetry collection.

**Verification**:

1. Verify no usage analytics collected or transmitted (page views, feature usage, session duration) → No usage analytics collection or transmission
2. Test that no performance metrics transmitted (rendering times, memory, CPU) → No performance metrics transmission
3. Verify no crash reports transmitted (stack traces, memory dumps, error logs) → No crash report transmission
4. Test that no debugging information transmitted (console logs, JavaScript errors) → No debugging information transmission
5. Verify no feature adoption metrics transmitted (feature usage, configuration) → No feature or system information transmission
6. Test that no system information transmitted (OS version, hardware, installed software) → No analytics SDKs or libraries present
7. Verify no network information transmitted (IP addresses, DNS queries, timing) → No crash reporting service integration
8. Test that no analytics SDKs or libraries included in browser → Zero telemetry transmission (verified via network monitoring)
9. Verify no crash reporting services integrated → Documentation states no telemetry
10. Test network monitoring shows zero telemetry transmission → Code review confirms no telemetry infrastructure

**Pass Criteria**: Zero telemetry of all types (usage, performance, crashes, debugging, features, system) AND no analytics SDKs AND no crash reporting services AND zero network transmission AND clear documentation AND code review verification

**Fail Criteria**: Any telemetry transmission OR analytics SDKs present OR crash reporting integrated OR network telemetry observed OR unclear documentation OR unverified code

**Evidence**: Network monitoring showing zero telemetry transmission, code review showing no analytics or telemetry libraries, binary analysis showing no telemetry endpoints, documentation stating no telemetry, privacy policy confirmation

**References**:

- Telemetry Privacy Risks: https://www.eff.org/deeplinks/2019/10/privacy-badger-now-fights-more-tracking-embedded-tweets
- GDPR Telemetry: https://gdpr.eu/what-is-gdpr/

### Assessment: RDPS-REQ-55 (No degradation when network connectivity unavailable)

**Reference**: RDPS-REQ-55 - Browser shall function without degradation when network connectivity unavailable (RDPS-0 requirement)

**Given**: A conformant browser claiming RDPS-0 capability (no remote data processing) for reliable offline operation

**Task**: This assessment verifies that browsers provide identical functionality and performance whether online or offline for all core features (rendering, applications, browsing, settings, developer tools, extensions, passwords, local storage) with no connectivity checks gating features, no error/warning messages, and equivalent performance metrics when tested with cached content.

**Verification**:

1. Verify all rendering capabilities work identically offline (HTML, CSS, JS, images, media, fonts) → All rendering capabilities identical offline
2. Test that web applications and scripts execute normally offline → Web applications execute normally offline
3. Verify browsing features fully functional offline (tabs, windows, navigation, bookmarks, history) → All browsing features functional offline
4. Test browser settings and configuration accessible offline without limitations → Settings and configuration fully accessible offline
5. Verify developer tools fully functional offline → Developer tools fully functional offline
6. Test extension management works offline (previously installed extensions) → Extension management operational offline
7. Verify password management and autofill work offline with local data → Password management and autofill work offline
8. Test local data storage operations work identically offline (cookies, localStorage, IndexedDB) → Local storage operations identical offline
9. Verify no connectivity checks before enabling features → No connectivity checks gating features
10. Test that no connectivity-dependent UI elements or degradation warnings shown → Performance metrics equivalent online/offline (verified with cached content)

**Pass Criteria**: All features identical offline AND no performance reduction AND no error/warning messages AND no feature limitations AND no connectivity checks AND equivalent performance metrics AND clear documentation

**Fail Criteria**: Reduced functionality offline OR degraded performance offline OR error/warning messages OR limited features OR connectivity checks gating features OR slower offline performance OR unclear documentation

**Evidence**: Offline functionality testing for all features, performance benchmarking (online vs offline with cached content), network monitoring during offline operation, error message audit, feature availability audit, UI element inspection, performance metrics comparison

**References**:

- Offline-First Web Applications: https://offlinefirst.org/
- Service Worker Offline Support: https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Offline_Service_workers
- Progressive Enhancement: https://www.w3.org/wiki/Graceful_degradation_versus_progressive_enhancement

### Assessment: RDPS-REQ-56 (No remote authentication or authorization services required)

**Reference**: RDPS-REQ-56 - No remote authentication or authorization services shall be required (RDPS-0 requirement)

**Given**: A conformant browser claiming RDPS-0 capability (no remote data processing) for local-only authentication

**Task**: This assessment verifies that browsers require no remote authentication or authorization for any functionality (installation, features, settings, data management, updates, security) with optional local authentication mechanisms only, local credential storage, identical online/offline behavior, and documentation confirming no remote authentication requirements.

**Verification**:

1. Verify no remote authentication required for installation and activation → No remote authentication for installation/activation
2. Test that all browser features accessible without online authentication → All features accessible without online authentication
3. Verify browser functionality works without remote authorization services → No remote authorization services required
4. Test local user data access requires no remote authentication → Local data access without remote authentication
5. Verify manual updates work without online validation → Manual updates without online validation
6. Test license validation, if any, does not require remote servers → No remote license validation required
7. Verify all security features operate without remote authentication → Security features independent of remote authentication
8. Test optional local authentication mechanisms work offline (master passwords, profiles, locks) → Optional local authentication works offline
9. Verify authentication data stored locally (encrypted database, OS credential manager) → Authentication data stored locally only
10. Test identical authentication behavior whether online or offline → Identical online/offline authentication behavior

**Pass Criteria**: Zero remote authentication requirements AND all features accessible without authentication AND local authentication only (if any) AND identical online/offline behavior AND local credential storage AND clear documentation

**Fail Criteria**: Any remote authentication required OR features gated by online authentication OR remote authorization services OR different online/offline behavior OR cloud-synced credentials OR unclear documentation

**Evidence**: Installation testing without network, feature access testing offline, authentication flow analysis showing local-only verification, network monitoring showing no authentication traffic, credential storage analysis showing local-only storage, online/offline behavior comparison, documentation review

**References**:

- Local Authentication: https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API
- Air-Gapped Authentication: https://csrc.nist.gov/glossary/term/authentication
- Privacy-Preserving Authentication: https://www.w3.org/TR/webauthn-3/

### Assessment: RDPS-REQ-57 (Local-only operation capabilities and limitations documentation)

**Reference**: RDPS-REQ-57 - Browser shall document all local-only operation capabilities and limitations (RDPS-0 requirement)

**Given**: A conformant browser claiming RDPS-0 capability (no remote data processing) for transparent operation

**Task**: This assessment verifies that browsers provide comprehensive documentation of local-only operation covering offline capabilities (rendering, apps, storage, extensions, security, dev tools), clearly stated limitations (features unavailable offline, no sync, manual updates), operational guidance (installation, backup, troubleshooting, migration), and offline-accessible formats (bundled, PDF, plain text).

**Verification**:

1. Verify documentation comprehensively describes offline capabilities (rendering, apps, storage, extensions, security, dev tools) → Comprehensive offline capabilities documented (all feature categories)
2. Test that limitations clearly stated (features unavailable offline, no sync, manual updates) → Limitations and unavailable features clearly stated
3. Verify operational guidance provided (installation, backup, troubleshooting, migration) → Operational guidance provided (installation, backup, troubleshooting, migration)
4. Test documentation accessible offline (included with installation, PDF, plain text) → Documentation accessible offline (bundled, PDF, plain text)
5. Verify supported web standards and features documented → Supported web standards and features listed
6. Test that service worker and offline storage capabilities explained → Offline storage APIs and limits documented
7. Verify data management procedures documented (limits, backup, export) → Extension offline compatibility explained
8. Test extension compatibility and limitations clearly explained → Security feature offline operation confirmed
9. Verify security feature offline operation documented → Data backup procedures detailed
10. Test that offline installation procedures clearly described → Troubleshooting and migration guidance provided

**Pass Criteria**: Comprehensive capability documentation AND clear limitation statements AND operational guidance AND offline-accessible documentation AND web standards coverage AND storage documentation AND extension compatibility AND security documentation AND backup procedures AND troubleshooting guidance

**Fail Criteria**: Incomplete capability documentation OR unclear limitations OR no operational guidance OR online-only documentation OR missing standards coverage OR no storage documentation OR unclear extension support OR no security documentation OR no backup procedures OR no troubleshooting guidance

**Evidence**: Documentation completeness review covering all required areas, offline documentation accessibility verification (bundled docs, PDF availability), capability accuracy testing (verify documented features work as described), limitation verification (confirm stated limitations accurate), operational guidance evaluation (installation, backup, troubleshooting procedures)

**References**:

- Technical Documentation Best Practices: https://www.writethedocs.org/guide/
- Offline Documentation Standards: https://www.w3.org/TR/offline-webapps/
- Air-Gapped System Documentation: https://www.cisecurity.org/controls

### Assessment: RDPS-REQ-58 (User notification that no data leaves local system)

**Reference**: RDPS-REQ-58 - Users shall be informed that no data leaves the local system (RDPS-0 requirement)

**Given**: A conformant browser claiming RDPS-0 capability (no remote data processing) for transparent privacy protection

**Task**: This assessment verifies that browsers clearly inform users that no data leaves the local system through multiple mechanisms (setup notification, settings statement, documentation, privacy policy) using clear non-technical language, prominent visibility, benefits explanation, technical verification methods for advanced users, and honest accurate implementation with easy ongoing access to privacy commitments.

**Verification**:

1. Verify clear notification during installation or first launch stating data remains local → Initial setup notification stating data remains local
2. Test prominent privacy statement in browser settings describing local-only operation → Prominent settings interface privacy statement
3. Verify about or help documentation explains no data transmission policy → About/help documentation explaining policy
4. Test privacy policy contains legally binding commitment to local-only operation → Privacy policy legal commitment to local-only operation
5. Verify optional visual indicators reinforcing local-only status → Clear, non-technical language used
6. Test language used is clear and non-technical (accessible to average users) → Prominent and visible notifications
7. Verify notifications prominent and visible (not buried in lengthy terms) → Benefits clearly explained
8. Test that benefits explained (privacy, offline operation, no dependency) → Contrast with cloud-dependent alternatives explained
9. Verify documentation includes network monitoring procedures for user verification → Technical verification methods documented
10. Test browser provides verification tools (network activity monitor, diagnostic mode) → Easy ongoing access to privacy commitments

**Pass Criteria**: Multiple notification mechanisms (setup, settings, docs, privacy policy) AND clear non-technical language AND prominent visibility AND benefits explained AND technical verification methods AND honest accurate claims AND easy ongoing access AND documentation complete

**Fail Criteria**: Single notification only OR technical jargon OR buried in terms OR benefits unexplained OR no verification methods OR inaccurate claims OR difficult to access OR incomplete documentation

**Evidence**: First-run notification screenshots, settings interface privacy statements, help documentation review, privacy policy legal commitment, language clarity assessment, notification prominence evaluation, verification method documentation, accuracy verification (network monitoring confirms zero transmission)

**References**:

- Privacy Notice Requirements: https://gdpr.eu/privacy-notice/
- Transparency and Consent: https://www.ftc.gov/business-guidance/privacy-security

### Assessment: RDPS-REQ-59 (All RDPS-1 requirements implemented for RDPS-2)

**Reference**: RDPS-REQ-59 - All RDPS-1 requirements shall be implemented for RDPS-2 capability (RDPS-2-REQ-1 requirement)

**Given**: A conformant browser claiming RDPS-2 capability (extended remote processing with sensitive data) that should also meet all RDPS-1 requirements

**Task**: This assessment verifies that browsers claiming RDPS-2 capability fully implement all 15 RDPS-1 requirements (RDPS-REQ-1 through RDPS-REQ-15) as baseline foundation, each meeting specified criteria without degradation from RDPS-2 enhancements, with documentation confirming RDPS-2 includes all RDPS-1 protections and no gaps or exceptions.

**Verification**:

1. Verify RDPS-1-REQ-1 implemented (offline functionality documented) per RDPS-REQ-1 assessment → RDPS-1-REQ-11 implemented (failure logging) per RDPS-REQ-11
2. Test RDPS-1-REQ-2 implemented (data classification) per RDPS-REQ-2 assessment → RDPS-1-REQ-12 implemented (graceful degradation) per RDPS-REQ-12
3. Verify RDPS-1-REQ-3 implemented (data criticality) per RDPS-REQ-3 assessment → RDPS-1-REQ-13 implemented (credential protection) per RDPS-REQ-13
4. Test RDPS-1-REQ-4 implemented (TLS 1.3+ encryption) per RDPS-REQ-4 assessment → RDPS-1-REQ-14 implemented (rate limiting) per RDPS-REQ-14
5. Verify RDPS-1-REQ-5 implemented (certificate validation) per RDPS-REQ-5 assessment → RDPS-1-REQ-15 implemented (data validation) per RDPS-REQ-15
6. Test RDPS-1-REQ-6 implemented (retry with backoff) per RDPS-REQ-6 assessment → All 15 RDPS-1 requirements fully implemented
7. Verify RDPS-1-REQ-7 implemented (local caching) per RDPS-REQ-7 assessment → Each requirement meets specified criteria
8. Test RDPS-1-REQ-8 implemented (secure authentication) per RDPS-REQ-8 assessment → RDPS-2 enhancements do not compromise RDPS-1 baseline
9. Verify RDPS-1-REQ-9 implemented (certificate pinning) per RDPS-REQ-9 assessment → Documentation confirms RDPS-2 includes all RDPS-1 protections
10. Test RDPS-1-REQ-10 implemented (timeout controls) per RDPS-REQ-10 assessment → No gaps or exceptions in RDPS-1 requirement implementation

**Pass Criteria**: All 15 RDPS-1 requirements fully implemented AND each meets specified criteria AND no degradation from RDPS-2 enhancements AND documentation confirms inclusion AND no gaps or exceptions

**Fail Criteria**: Any RDPS-1 requirement not implemented OR any requirement fails criteria OR RDPS-2 compromises RDPS-1 baseline OR documentation does not confirm inclusion OR gaps or exceptions present

**Evidence**: RDPS-REQ-1 through RDPS-REQ-15 assessment results (all pass), comprehensive requirement coverage verification, baseline security preservation testing, documentation review confirming RDPS-2 includes all RDPS-1 protections, gap analysis showing complete RDPS-1 implementation

**References**:

- Defense in Depth: https://csrc.nist.gov/glossary/term/defense_in_depth
- Layered Security: https://www.nist.gov/cybersecurity
- Security Capability Levels: https://www.iso.org/standard/56328.html

### Assessment: RDPS-REQ-60 (All RDPS-2 requirements implemented for RDPS-3)

**Reference**: RDPS-REQ-60 - All RDPS-2 requirements shall be implemented for RDPS-3 capability (RDPS-3-REQ-1 requirement)

**Given**: A conformant browser claiming RDPS-3 capability (full remote processing with critical data requiring maximum security) that should also meet all RDPS-2 requirements

**Task**: This assessment verifies that browsers claiming RDPS-3 capability fully implement all 18 RDPS-2 requirements (including 15 RDPS-1 requirements via RDPS-2-REQ-1) as verified through RDPS-REQ-1 through RDPS-REQ-32 assessments, each meeting specified criteria without degradation from RDPS-3 enhancements, with documentation confirming RDPS-3 includes all RDPS-2 and RDPS-1 protections and no gaps or exceptions.

**Verification**:

1. Verify all RDPS-1 requirements implemented via RDPS-REQ-59 assessment (15 requirements) → RDPS-2-REQ-11 (replay defense) per RDPS-REQ-25
2. Test RDPS-2-REQ-2 implemented (encryption at rest) per RDPS-REQ-16 assessment → RDPS-2-REQ-12 (data minimization) per RDPS-REQ-26
3. Verify RDPS-2-REQ-3 implemented (mutual TLS) per RDPS-REQ-17 assessment → RDPS-2-REQ-13 (sync controls) per RDPS-REQ-27
4. Test RDPS-2-REQ-4 implemented (redundant copies) per RDPS-REQ-18 assessment → RDPS-2-REQ-14 (data export) per RDPS-REQ-28
5. Verify RDPS-2-REQ-5 implemented (backup recovery) per RDPS-REQ-19 assessment → RDPS-2-REQ-15 (endpoint config) per RDPS-REQ-29
6. Test RDPS-2-REQ-6 implemented (retention policies) per RDPS-REQ-20 assessment → RDPS-2-REQ-16 (availability) per RDPS-REQ-30
7. Verify RDPS-2-REQ-7 implemented (access controls) per RDPS-REQ-21 assessment → RDPS-2-REQ-17 (pooling) per RDPS-REQ-31
8. Test RDPS-2-REQ-8 implemented (audit logging) per RDPS-REQ-22 assessment → RDPS-2-REQ-18 (token protection) per RDPS-REQ-32
9. Verify RDPS-2-REQ-9 implemented (integrity verification) per RDPS-REQ-23 assessment → All 18 RDPS-2 requirements fully implemented (includes RDPS-1 via RDPS-2-REQ-1)
10. Test RDPS-2-REQ-10 implemented (endpoint protection) per RDPS-REQ-24 assessment → RDPS-3 enhancements do not compromise RDPS-1/RDPS-2 baseline

**Pass Criteria**: All 18 RDPS-2 requirements fully implemented (including 15 RDPS-1 via RDPS-2-REQ-1) AND each meets specified criteria AND no degradation from RDPS-3 enhancements AND documentation confirms inclusion AND no gaps or exceptions

**Fail Criteria**: Any RDPS-2 requirement not implemented OR any requirement fails criteria OR RDPS-3 compromises RDPS-2/RDPS-1 baseline OR documentation does not confirm inclusion OR gaps or exceptions present

**Evidence**: RDPS-REQ-1 through RDPS-REQ-32 assessment results (all pass), comprehensive requirement coverage verification across all three capability levels, baseline security preservation testing, documentation review confirming RDPS-3 includes all RDPS-2 and RDPS-1 protections, gap analysis showing complete RDPS-2 implementation

**References**:

- Defense in Depth: https://csrc.nist.gov/glossary/term/defense_in_depth
- Layered Security Architecture: https://www.nist.gov/cybersecurity
- Enterprise Security Capability Maturity: https://www.iso.org/standard/56328.html

# Annex A (informative): Mapping between the present document and CRA requirements

_Table mapping technical security requirements from Section 5 of the present document to essential cybersecurity requirements in Annex I of the CRA. The purpose of this is to help identify missing technical security requirements._

| CRA requirement                                 | Technical security requirements(s) |
|-------------------------------------------------|------------------------------------|
| No known exploitable vulnerabilities            | UPD-0-REQ-1 through UPD-0-REQ-24 (Forced automatic updates), UPD-1-REQ-1 through UPD-1-REQ-25 (Automatic updates with postponement), LOG-REQ-14 (Incident detection), LOG-REQ-15 (Audit trail completeness), EMB-REQ-9 (JavaScript bridge security review), EXT-REQ-4 (Manifest validation), EXT-REQ-17 (Extension signature validation) |
| Secure design, development, production          | EMB-REQ-9 (JavaScript bridge security review), EXT-REQ-4 (Manifest validation), EXT-REQ-17 (Extension signature validation), UPD-REQ-2 (Update signature verification), UPD-REQ-23 (Binary reproducibility), ENC-REQ-12 (Secure random number generation), SYS-REQ-26 (Sandbox escape prevention), SYS-REQ-27 (Spectre/Meltdown mitigations), SYS-REQ-28 (Side-channel mitigations) |
| Secure by default configuration                 | DOM-0-REQ-1 through DOM-0-REQ-6 (Full isolation by default), ENC-0-REQ-1 through ENC-0-REQ-23 (Full encryption by default), DOM-REQ-5 (SameSite=Lax default), DOM-REQ-12 (document.domain restricted by default), ENC-REQ-16 (HTTPS-first mode), UPD-0-REQ-1 (Automatic updates enabled by default), LOG-REQ-9 (User consent for telemetry), SYS-0-REQ-1 through SYS-0-REQ-13 (Sandboxed by default), EMB-0-REQ-1 through EMB-0-REQ-7 (Isolated by default) |
| Secure updates                                  | UPD-REQ-1 (Automatic update mechanism), UPD-REQ-2 (Update signature verification), UPD-REQ-3 (HTTPS-only delivery), UPD-REQ-4 (Manifest integrity), UPD-REQ-5 (Rollback protection), UPD-REQ-6 (Channel isolation), UPD-REQ-7 (Component updates), UPD-REQ-8 (Emergency updates), UPD-REQ-9 (Verification before installation), UPD-REQ-10 (Failure recovery), UPD-REQ-11 (Transparency logging), UPD-REQ-12 (Delta update security), UPD-REQ-13 (Server authentication), UPD-REQ-14 (Timing jitter), UPD-REQ-15 (Background enforcement), UPD-REQ-16 (Notification UI), UPD-REQ-17 (Forced critical updates), UPD-REQ-18 (Verification chain), UPD-REQ-19 (Source pinning), UPD-REQ-20 (Integrity verification), UPD-REQ-21 (Staged rollout), UPD-REQ-22 (Domain validation), UPD-REQ-23 (Binary reproducibility), EXT-REQ-10 (Extension update verification) |
| Authentication and access control mechanisms    | DOM-REQ-1 (Process-per-site isolation), DOM-REQ-3 (Cross-origin DOM access prevention), DOM-REQ-4 (CORS preflight), DOM-REQ-5 (SameSite cookies), DOM-REQ-6 (Storage isolation), EXT-REQ-1 (Extension permission model), EXT-REQ-3 (Extension API access control), EXT-REQ-7 (Host permissions validation), SYS-REQ-6 (Device API permissions), SYS-REQ-7 (PWA permission management), SYS-REQ-8 through SYS-REQ-19 (Device-specific permissions), EMB-REQ-1 (JavaScript bridge API allowlists), EMB-REQ-5 (User consent for sensitive operations), EMB-REQ-11 (Granular capability-based permissions), PRO-REQ-2 (User consent for custom protocols), PRO-REQ-3 (Protocol allowlist enforcement) |
| Confidentiality protection                      | ENC-REQ-1 (TLS 1.3+ support), ENC-REQ-2 (Certificate validation), ENC-REQ-3 (Certificate pinning), ENC-REQ-4 (HSTS enforcement), ENC-REQ-5 (Mixed content blocking), ENC-REQ-6 (Certificate Transparency), ENC-REQ-11 (Web Crypto API), ENC-REQ-13 (Subresource Integrity), ENC-REQ-14 (Encrypted SNI/ECH), ENC-REQ-16 (HTTPS-first mode), ENC-REQ-20 (Cryptographic key isolation), ENC-REQ-21 (Certificate store security), DOM-REQ-2 (CORB), DOM-REQ-6 (Storage isolation), EMB-REQ-4 (Context isolation), EMB-REQ-8 (Host credential protection), EMB-REQ-12 (Storage isolation from host), EMB-REQ-14 (Encrypted cross-process bridge), EMB-REQ-17 (Certificate validation for embedded content), EMB-REQ-21 (Mixed content prevention), EMB-REQ-27 (Network security configuration) |
| Integrity protection for data and configuration | ENC-REQ-2 (Certificate validation), ENC-REQ-13 (Subresource Integrity), UPD-REQ-2 (Update signature verification), UPD-REQ-4 (Update manifest integrity), UPD-REQ-5 (Rollback protection), UPD-REQ-20 (Update integrity verification), LOG-REQ-11 (Log integrity protection), EMB-REQ-2 (JavaScript bridge input validation), EMB-REQ-7 (Immutable bridge configuration), EMB-REQ-19 (SRI for embedded content), EMB-REQ-23 (Cryptographic signature verification for local content), EXT-REQ-4 (Manifest validation), EXT-REQ-17 (Extension signature validation), DOM-REQ-9 (CORP), DOM-REQ-11 (COEP) |
| Data minimization                               | LOG-REQ-7 (Log data minimization), LOG-REQ-8 (Log anonymization), LOG-REQ-12 (Log retention policies), LOG-REQ-18 (Privacy-preserving analytics), EXT-REQ-16 (Extension telemetry privacy), DOM-REQ-6 (Storage isolation limits data sharing), EMB-REQ-12 (Storage isolation from host), PRO-REQ-5 (Protocol parameter sanitization to prevent data leakage) |
| Availability protection                         | SYS-REQ-20 (Hardware resource limits), SYS-REQ-21 (Memory isolation), SYS-REQ-22 (CPU quotas), SYS-REQ-23 (Network bandwidth limits), SYS-REQ-24 (Storage quotas), SYS-REQ-25 (Process priority management), UPD-REQ-10 (Update failure recovery), UPD-REQ-21 (Staged rollout), EMB-REQ-10 (Bridge API rate limiting), EXT-REQ-5 (Extension sandboxing to prevent interference) |
| Minimize impact on other devices or services    | DOM-REQ-1 (Process-per-site isolation), SYS-REQ-1 (Process sandbox enforcement), SYS-REQ-2 (Renderer process isolation), SYS-REQ-3 (GPU process isolation), SYS-REQ-4 (Network service isolation), SYS-REQ-20 (Resource limits), SYS-REQ-26 (Sandbox escape prevention), EXT-REQ-5 (Extension sandboxing), EXT-REQ-6 (Cross-extension isolation), EMB-REQ-4 (Context isolation), PRO-REQ-13 (Handler capability restrictions) |
| Limit attack surface                            | EXT-0-REQ-1 through EXT-0-REQ-3 (No extension support), SYS-0-REQ-1 through SYS-0-REQ-13 (Fully sandboxed), EMB-0-REQ-1 through EMB-0-REQ-7 (No JavaScript bridge), PRO-0-REQ-1 through PRO-0-REQ-5 (HTTP/HTTPS only), DOM-REQ-7 (iframe sandboxing), DOM-REQ-8 (Opaque origin handling), EMB-REQ-6 (No system-level API exposure), EMB-REQ-16 (Allowlists over denylists), EXT-REQ-12 (Background script restrictions), ENC-REQ-19 (Legacy crypto deprecation) |
| Exploit mitigation by limiting incident impact  | DOM-REQ-1 (Process-per-site isolation limits cross-site impact), SYS-REQ-1 (Sandbox enforcement), SYS-REQ-2 (Process isolation), SYS-REQ-21 (Memory isolation), SYS-REQ-26 (Sandbox escape prevention), SYS-REQ-27 (Spectre/Meltdown mitigations), SYS-REQ-28 (Side-channel mitigations), DOM-REQ-2 (CORB), DOM-REQ-9 (CORP), DOM-REQ-10 (COOP), DOM-REQ-11 (COEP), EXT-REQ-2 (Content script isolation), EXT-REQ-5 (Extension sandboxing), EXT-REQ-6 (Cross-extension isolation), EMB-REQ-4 (Context isolation), UPD-REQ-5 (Rollback protection), UPD-REQ-21 (Staged rollout limits blast radius) |
| Logging and monitoring mechanisms               | LOG-REQ-1 (Security event logging), LOG-REQ-2 (Certificate error logging), LOG-REQ-3 (Extension security events), LOG-REQ-4 (CSP violation reporting), LOG-REQ-5 (Network Error Logging), LOG-REQ-6 (Crash reporting), LOG-REQ-10 (Secure log transmission), LOG-REQ-11 (Log integrity protection), LOG-REQ-13 (Security dashboard), LOG-REQ-14 (Incident detection), LOG-REQ-15 (Audit trail completeness), LOG-REQ-16 (Real-time security alerts), LOG-REQ-17 (Forensic log export), LOG-REQ-19 (Compliance logging), LOG-REQ-20 (Log access controls), EMB-REQ-3 (JavaScript bridge logging), EMB-REQ-22 (Trust decision logging), EMB-REQ-32 (Trust boundary violation events), UPD-REQ-11 (Update transparency logging), PRO-REQ-9 (Protocol handler logging) |
| Secure deletion and data transfer               | DOM-REQ-6 (Storage isolation enables secure per-origin deletion), ENC-REQ-1 (TLS 1.3+ for secure transfer), ENC-REQ-3 (Certificate pinning for critical transfers), ENC-REQ-5 (Mixed content blocking), EMB-REQ-17 (Certificate validation for embedded content transfers), EMB-REQ-21 (Mixed content prevention), EMB-REQ-27 (Network security configuration), SYS-REQ-24 (Storage quotas with cleanup mechanisms), EXT-REQ-11 (Extension storage isolation enables clean uninstall) |

# Annex B (informative): Mapping of Use Cases to Capabilities and Requirements

This annex provides a comprehensive mapping of each use case defined in Section 4.4 to the relevant browser capabilities and their associated requirement sets. This mapping helps manufacturers and assessors identify which requirements apply to specific deployment contexts.

## B.1 Use Case Mapping Methodology

For each use case, the mapping identifies:

1. **Primary Capabilities**: Core security capabilities that are essential for the use case
2. **Recommended Condition Levels**: Specific condition levels (e.g., DOM-1, EXT-2) appropriate for the use case's risk profile
3. **Critical Requirements**: Specific requirement sets that are satisfied for the use case
4. **Optional Enhancements**: Additional requirements that may be appropriate based on deployment specifics

## B.2 Use Case to Capability Mappings

### UC-B1: General Purpose Web Browsing (Risk Level: Standard)

**Primary Capabilities and Recommended Conditions**:

- **DOM (Domain/Origin Isolation)**: DOM-1 (Controlled isolation)
- **EXT (Extension System)**: EXT-1 or EXT-2
- **ENC (Encryption)**: ENC-1
- **LOG (Logging/Monitoring)**: LOG-1
- **UPD (Updates)**: UPD-1
- **PRO (Protocol Handlers)**: PRO-1
- **SYS (System Resources)**: SYS-1

**Critical Requirements**: DOM-1-REQ-1 through DOM-1-REQ-9, ENC-1-REQ-1 through ENC-1-REQ-19, UPD-1-REQ-1 through UPD-1-REQ-25, EXT-1-REQ-1 through EXT-1-REQ-14, LOG-1-REQ-1 through LOG-1-REQ-18, SYS-1-REQ-1 through SYS-1-REQ-22

**Assessment References**: All DOM, ENC, UPD, EXT, LOG, PRO, SYS assessments apply

---

### UC-B2: Development and Testing Environments (Risk Level: High)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-2
- **EXT**: EXT-2
- **ENC**: ENC-1
- **LOG**: LOG-2
- **UPD**: UPD-1 or UPD-2
- **PRO**: PRO-2
- **SYS**: SYS-2

**Critical Requirements**: DOM-2-REQ-1 through DOM-2-REQ-12, EXT-2-REQ-1 through EXT-2-REQ-10, LOG-2-REQ-1 through LOG-2-REQ-20, PRO-2-REQ-1 through PRO-2-REQ-12, SYS-2-REQ-1 through SYS-2-REQ-15

**Assessment References**: All capability assessments, emphasis on EXT-REQ-9, DOM-REQ-9-11, SYS-REQ-14-17

---

### UC-B3: Kiosks and Shared Terminals (Risk Level: High)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-0 or DOM-1
- **EXT**: EXT-0
- **ENC**: ENC-0 or ENC-1
- **LOG**: LOG-3
- **UPD**: UPD-0
- **PRO**: PRO-0
- **SYS**: SYS-0
- **EMB** (if embedded): EMB-1 or EMB-2

**Critical Requirements**: DOM-0-REQ-1 through DOM-0-REQ-6, EXT-0-REQ-1 through EXT-0-REQ-3, ENC-0-REQ-1 through ENC-0-REQ-23, LOG-3-REQ-1 through LOG-3-REQ-20, UPD-0-REQ-1 through UPD-0-REQ-24, PRO-0-REQ-1 through PRO-0-REQ-5, SYS-0-REQ-1 through SYS-0-REQ-13

**If Embedded**: EMB-1-REQ-1 through EMB-1-REQ-17, EMB-REQ-8, EMB-REQ-3, EMB-REQ-22

**Additional**: Domain allowlisting, session auto-termination, no credential storage, remote monitoring

**Assessment References**: Strictest criteria; DOM-REQ-1-8, ENC-REQ-1-6, UPD-REQ-1-11, SYS-REQ-1-4, LOG-REQ-10-11

---

### UC-B4: Financial Services Access (Risk Level: High)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-1
- **EXT**: EXT-1
- **ENC**: ENC-0 or ENC-1
- **LOG**: LOG-1
- **UPD**: UPD-0 or UPD-1
- **PRO**: PRO-1
- **SYS**: SYS-1
- **EMB** (if embedded): EMB-1 or EMB-2

**Critical Requirements**: ENC-0-REQ-1 through ENC-0-REQ-23 OR ENC-1-REQ-1 through ENC-1-REQ-19, DOM-1-REQ-1 through DOM-1-REQ-9, EXT-1-REQ-1 through EXT-1-REQ-14, LOG-REQ-2, LOG-REQ-14

**If Embedded**: EMB-1-REQ-1 through EMB-1-REQ-17, EMB-REQ-17, EMB-REQ-20, EMB-REQ-2, EMB-REQ-8

**Assessment References**: ENC-REQ-1-7, ENC-REQ-17, DOM-REQ-5, LOG-REQ-2, EMB-REQ-1-10 (if embedded)

---

### UC-B5: Healthcare and Medical Systems (Risk Level: High)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-1 or DOM-2
- **EXT**: EXT-1
- **ENC**: ENC-0
- **LOG**: LOG-3
- **UPD**: UPD-0 or UPD-1
- **PRO**: PRO-1
- **SYS**: SYS-1
- **EMB** (if embedded): EMB-1 or EMB-2

**Critical Requirements**: ENC-0-REQ-1 through ENC-0-REQ-23, LOG-3-REQ-1 through LOG-3-REQ-20, LOG-REQ-7, LOG-REQ-8, LOG-REQ-19, DOM-1-REQ-1 through DOM-1-REQ-9, UPD-0-REQ-17, EXT-1-REQ-1 through EXT-1-REQ-14

**If Embedded**: EMB-1-REQ-1 through EMB-1-REQ-17, EMB-REQ-8, EMB-REQ-3, EMB-REQ-22

**Compliance**: GDPR data protection, session re-auth, auto-timeout, audit trails

**Assessment References**: ENC-REQ-1-7, LOG-REQ-7-9, LOG-REQ-19, LOG-REQ-11, EMB-REQ-3, EMB-REQ-22 (if embedded)

---

### UC-B6: E-Government Services Access (Risk Level: High)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-1
- **EXT**: EXT-1
- **ENC**: ENC-0
- **LOG**: LOG-2 or LOG-3
- **UPD**: UPD-0 or UPD-1
- **PRO**: PRO-1
- **SYS**: SYS-1 or SYS-2

**Critical Requirements**: ENC-0-REQ-1 through ENC-0-REQ-23, ENC-REQ-2, ENC-REQ-3, SYS-REQ-29, DOM-1-REQ-1 through DOM-1-REQ-9, LOG-REQ-15, UPD-0-REQ-1 through UPD-0-REQ-24

**Special**: Digital signatures, smart card integration, eIDAS compliance, legal non-repudiation

**Assessment References**: ENC-REQ-2-3, ENC-REQ-6, SYS-REQ-29, LOG-REQ-15

---

### UC-B7: Enterprise Applications (Risk Level: High)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-2
- **EXT**: EXT-1 or EXT-2
- **ENC**: ENC-1
- **LOG**: LOG-3
- **UPD**: UPD-0 or UPD-1
- **PRO**: PRO-2
- **SYS**: SYS-2
- **EMB** (if Electron/CEF/Tauri): EMB-2 or EMB-3

**Critical Requirements**: DOM-2-REQ-1 through DOM-2-REQ-12, LOG-3-REQ-1 through LOG-3-REQ-20, LOG-REQ-13, LOG-REQ-14, LOG-REQ-16, EXT-2-REQ-10, UPD-0-REQ-1 through UPD-0-REQ-24, PRO-2-REQ-11, SYS-2-REQ-11 through SYS-2-REQ-15

**Enterprise Features**: SSO, DLP, extension allowlisting, profile separation, BYOD containerization

**Assessment References**: DOM-REQ-9-11, LOG-REQ-13-16, LOG-REQ-19, EXT-REQ-3, PRO-REQ-3, SYS-REQ-7

---

### UC-B8: Critical Infrastructure (Risk Level: CRITICAL)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-0 or DOM-1
- **EXT**: EXT-0
- **ENC**: ENC-0
- **LOG**: LOG-3
- **UPD**: UPD-0
- **PRO**: PRO-0 or PRO-1
- **SYS**: SYS-0 or SYS-1
- **EMB** (if SCADA/ICS): EMB-0 or EMB-1

**Critical Requirements**: DOM-0-REQ-1 through DOM-0-REQ-6, EXT-0-REQ-1 through EXT-0-REQ-3, ENC-0-REQ-1 through ENC-0-REQ-23, LOG-3-REQ-1 through LOG-3-REQ-20, LOG-REQ-11, UPD-0-REQ-1 through UPD-0-REQ-24, UPD-REQ-5, UPD-REQ-11, PRO-0-REQ-1 through PRO-0-REQ-5, SYS-0-REQ-1 through SYS-0-REQ-13

**If Embedded**: EMB-0-REQ-1 through EMB-0-REQ-7, EMB-REQ-17, EMB-REQ-20, EMB-REQ-27, EMB-REQ-31

**Additional**: Zero trust, mTLS, RBAC, air-gapped deployment, supply chain controls, physical security

**Assessment References**: ALL assessments at strictest criteria; ENC-REQ-1-11, UPD-REQ-1-11, LOG-REQ-10-11, SYS-REQ-26-28, EMB-REQ-17-31 (if embedded)

---

### UC-B9: Security Research (Risk Level: CRITICAL)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-2 or DOM-3
- **EXT**: EXT-3
- **ENC**: ENC-1
- **LOG**: LOG-3
- **UPD**: UPD-2 or UPD-3
- **PRO**: PRO-3
- **SYS**: SYS-3

**Critical Requirements**: LOG-3-REQ-1 through LOG-3-REQ-20, LOG-REQ-6, LOG-REQ-17, DOM-3-REQ-9, EXT-3-REQ-9 through EXT-3-REQ-12, SYS-3-REQ-15

**Environment Isolation**: Disposable VMs, network capture, air-gapped zones, snapshot/rollback, behavioral logging

**Important**: Deploy ONLY in isolated research environments; NOT for production

**Assessment References**: LOG-REQ-1-20, LOG-REQ-17, EXT-REQ-4, all assessments in adversarial conditions

---

### UC-B10: Adapted Browser with Modified Features (Risk Level: Standard to High)

**Primary Capabilities and Recommended Conditions**:

- **All capabilities**: Inherit from upstream browser
- **LOG**: May vary (LOG-1, LOG-2, or LOG-3)
- **UPD**: UPD-0 or UPD-1 (manufacturer-controlled)
- **EMB** (if native integration added): EMB-2 or EMB-3

**Critical Requirements**: All upstream requirements PLUS UPD-REQ-2, UPD-REQ-11, EMB-REQ-9, LOG-REQ-9, LOG-REQ-7, LOG-REQ-8

**If Native Integration Added**: EMB-2-REQ-1 through EMB-2-REQ-10 OR EMB-3-REQ-1 through EMB-3-REQ-12, EMB-REQ-1, EMB-REQ-2, EMB-REQ-3, EMB-REQ-9

**For Bundled Extensions**: EXT-REQ-4, EXT-REQ-17, supply chain security

**Manufacturer Obligations**: Timely upstream patches, security review, transparency, maintaining security controls, supply chain security