Update file EN-304-618.md

opportunities; anonymous usage options avoiding account requirements where

possible; and data residency controls respecting jurisdictional requirements.

## 4.6 Password Manager Security Requirements

# 5 Password Manager Security Requirements

### 4.6.1 Master Password Authentication

## 5.1 Master Password Authentication

### Capability

Password manager employs master password authentication mechanism for primary

access control.

Password manager employs master password authentication mechanism for primary access control.

### Condition

Master password authentication mechanism exposed without adequate protection

against brute force or credential attacks.

Master password authentication mechanism exposed without adequate protection against brute force or credential attacks.

### Threat

### Risk

**HIGH** - Compromise of master password provides complete access to all stored

credentials. Likelihood elevated due to targeted nature of password manager

attacks.

**HIGH** - Compromise of master password provides complete access to all stored credentials. Likelihood elevated due to targeted nature of password manager attacks.

### Requirement

-   **R1.1**: SHALL implement key derivation function (KDF) with minimum 100,000

    iterations (PBKDF2) or equivalent computational cost

-   **R1.2**: SHALL enforce minimum master password complexity (12+ characters,

    multiple character classes)

-   **R1.3**: SHALL implement exponential backoff for failed authentication

    attempts

-   **R1.1**: SHALL implement key derivation function (KDF) with minimum 100,000 iterations (PBKDF2) or equivalent computational cost

-   **R1.2**: SHALL enforce minimum master password complexity (12+ characters, multiple character classes)

-   **R1.3**: SHALL implement exponential backoff for failed authentication attempts

-   **R1.4**: SHALL clear master password from memory immediately after use

-   **R1.5**: SHALL support multi-factor authentication as mandatory option

-   **R1.5a**: SHALL support multi-factor authentication as mandatory option

-   **R1.5b**: SHALL mask password entry fields and implement anti-keylogging measures

### 4.6.2 Password Database Storage

## 5.2 Password Database Storage

### Capability

Encrypted storage mechanism for password database (local storage or cloud

synchronization).

Encrypted storage mechanism for password database (local storage or cloud synchronization).

### Condition

Password database stored or transmitted with insufficient encryption or key

management practices.

Password database stored or transmitted with insufficient encryption or key management practices.

### Threat

### Risk

**CRITICAL** - Database contains all user credentials. Impact is catastrophic if

encryption is compromised.

**CRITICAL** - Database contains all user credentials. Impact is catastrophic if encryption is compromised.

### Requirement

-   **R2.1**: SHALL use AES-256 or equivalent approved encryption algorithm

-   **R2.2**: SHALL implement authenticated encryption (AEAD) to ensure

    integrity

-   **R2.3**: SHALL use unique salts per database

-   **R2.4**: SHALL implement secure key derivation separate from authentication

-   **R2.5**: SHALL use TLS 1.3 or higher for all network transmissions

-   **R2.1a**: SHALL use AES-256 or equivalent approved encryption algorithm

-   **R2.1b**: SHALL use unique salts per database

-   **R2.2**: SHALL implement authenticated encryption (AEAD) to ensure integrity

-   **R2.2b**: SHALL implement secure key derivation separate from authentication

-   **R2.3**: SHALL use TLS 1.3 or higher for all network transmissions

-   **R2.4**: SHALL implement countermeasures against side-channel attacks (constant-time operations, memory access patterns)

### 4.6.3 Auto-fill Functionality

## 5.3 Auto-fill Functionality

### Capability

### Condition

Auto-fill mechanism operating without proper origin validation or user

confirmation.

Auto-fill mechanism operating without proper origin validation or user confirmation.

### Threat

### Risk

**HIGH** - Auto-fill vulnerabilities enable credential theft at scale.

Likelihood high due to prevalence of phishing.

**HIGH** - Auto-fill vulnerabilities enable credential theft at scale. Likelihood high due to prevalence of phishing.

### Requirement

-   **R3.1**: SHALL validate exact domain match before auto-fill

-   **R3.2**: SHALL require explicit user interaction for credential insertion

-   **R3.3**: SHALL implement Content Security Policy (CSP) in browser

    extensions

-   **R3.4**: SHALL NOT auto-fill on HTTP sites

-   **R3.5**: SHALL maintain domain whitelist/blacklist capability

-   **R3.3a**: SHALL implement Content Security Policy (CSP) in browser extensions

-   **R3.3b**: SHALL NOT auto-fill on HTTP sites

-   **R3.4**: SHALL maintain domain whitelist/blacklist capability

### 4.6.4 Import/Export Functionality

## 5.4 Import/Export Functionality

### Capability

Data portability features allowing credential import from and export to external

formats.

Data portability features allowing credential import from and export to external formats.

### Condition

Import/export operations handling sensitive data without adequate protection or

validation.

Import/export operations handling sensitive data without adequate protection or validation.

### Threat

### Risk

**MEDIUM** - Feature typically used infrequently but presents data exposure

risk. Impact high if exploited.

**MEDIUM** - Feature typically used infrequently but presents data exposure risk. Impact high if exploited.

### Requirement

-   **R4.1**: SHALL provide encrypted export option as default

-   **R4.2**: SHALL validate and sanitize all imported data

-   **R4.2a**: SHALL validate and sanitize all imported data

-   **R4.2b**: SHALL implement format validation and type checking

-   **R4.3**: SHALL securely overwrite temporary files

-   **R4.4**: SHALL require re-authentication for export operations

-   **R4.5**: SHALL log all import/export activities

### 4.6.5 API/CLI Access

## 5.5 API/CLI Access

### Capability

Programmatic access interface for integration with external systems or

automation.

Programmatic access interface for integration with external systems or automation.

### Condition

### Risk

**HIGH** - APIs present expanded attack surface. Automation enables rapid

exploitation at scale.

**HIGH** - APIs present expanded attack surface. Automation enables rapid exploitation at scale.

### Requirement

-   **R5.1**: SHALL implement OAuth 2.0 or equivalent secure authentication

-   **R5.2**: SHALL enforce rate limiting per endpoint

-   **R5.1a**: SHALL implement OAuth 2.0 or equivalent secure authentication

-   **R5.1b**: SHALL use short-lived tokens with secure refresh mechanisms

-   **R5.2a**: SHALL enforce rate limiting per endpoint

-   **R5.2b**: SHALL implement principle of least privilege for API permissions

-   **R5.3**: SHALL maintain comprehensive audit logs with tamper protection

-   **R5.4**: SHALL implement principle of least privilege for API permissions

-   **R5.5**: SHALL support API key rotation without service disruption

-   **R5.4**: SHALL support API key rotation without service disruption

-   **R5.5**: SHALL implement token binding or proof-of-possession mechanisms

## 4.6.6 Backup and Recovery

## 5.6 Backup and Recovery

### Capability

### Condition

Recovery mechanisms that bypass normal security controls or create alternative

access paths.

Recovery mechanisms that bypass normal security controls or create alternative access paths.

### Threat

### Risk

**HIGH** - Recovery mechanisms are frequently targeted as the weakest link.

Impact equals full account compromise.

**HIGH** - Recovery mechanisms are frequently targeted as the weakest link. Impact equals full account compromise.

### Requirement

-   **R6.1**: SHALL encrypt all backup data with same standards as primary

    database

-   **R6.2**: SHALL implement multi-factor recovery process

-   **R6.3**: SHALL generate cryptographically random recovery codes (minimum

    128 bits entropy)

-   **R6.4**: SHALL notify users of all recovery attempts

-   **R6.5**: SHALL implement time-delayed recovery with notification period

-   **R6.1**: SHALL encrypt all backup data with same standards as primary database

-   **R6.2a**: SHALL implement multi-factor recovery process

-   **R6.2b**: SHALL implement time-delayed recovery with notification period

-   **R6.3**: SHALL generate cryptographically random recovery codes (minimum 128 bits entropy)

-   **R6.4a**: SHALL notify users of all recovery attempts

-   **R6.4b**: SHALL limit recovery code usage attempts

## 4.7.7 Password Generation

## 5.7 Password Generation

### Capability

Cryptographically secure random password generation with configurable parameters.

### Condition

Password generator using predictable or weak randomness sources.

### Threat

-   **T7.1**: Predictable password generation enabling pre-computation attacks

-   **T7.2**: Insufficient entropy in generated passwords

-   **T7.3**: Side-channel leakage of generation parameters

-   **T7.4**: Compromise of random number generator state

### Risk

**MEDIUM** - Weak password generation undermines security premise. Likelihood depends on implementation quality.

### Requirement

-   **R7.1**: SHALL use cryptographically secure random number generator (CSRNG)

-   **R7.2**: SHALL provide minimum acceptable bits of entropy for generated passwords

-   **R7.3**: SHALL allow user-defined generation parameters

-   **R7.4**: SHALL implement secure random seed initialization

-   **R7.5**: SHALL NOT store or log generated passwords before user acceptance

-   **R7.6**: SHALL implement constant-time generation to prevent timing analysis

## 5.8 Workload Isolation

### Capability

Isolation enforcement between concurrent workloads, administrative functions, and network domains.

### Condition

Inadequate separation between concurrently executing workloads (e.g., remote synchronisation and secret injection).

### Threat

-   **T8.1**: Cross-workload memory access violations

-   **T8.2**: Execution state interference between processes

-   **T8.3**: Isolation boundary escape leading to privilege escalation

-   **T8.4**: Side-channel attacks between isolated components

### Risk

**HIGH** - Compromises integrity, confidentiality, and authorization controls. Enables lateral movement between security domains.

### Requirement

-   **R8.1a**: SHALL enforce process isolation using OS-level security boundaries

-   **R8.1b**: SHALL prevent unauthorized inter-process communication

-   **R8.2**: SHALL implement separate memory spaces for each workload

-   **R8.3a**: SHALL enforce network segmentation between administrative and user functions

-   **R8.3b**: SHALL monitor and alert on isolation violation attempts

-   **R8.4b**: SHALL implement side-channel resistant isolation (cache partitioning, timing isolation)

## 5.9 Platform Integrity

### Capability

Runtime and at-rest integrity protection for platform components and workloads.

### Condition

Insufficient protection of user interface or memory buffers against tampering.

### Threat

-   **T9.1**: Code injection through UI manipulation

-   **T9.2**: Memory buffer overflow attacks

-   **T9.3**: Binary patching of core components

-   **T9.4**: Configuration file tampering

### Risk

**HIGH** - Compromises integrity and authorization mechanisms. Enables persistent malware installation.

### Requirement

-   **R9.1a**: SHALL implement code signing for all executable components

-   **R9.1b**: SHALL perform runtime integrity checks on critical functions

-   **R9.2**: SHALL use address space layout randomization (ASLR)

-   **R9.3**: SHALL implement buffer overflow protections

-   **R9.4**: SHALL maintain cryptographic hashes of configuration files

## 5.10 Platform Attestation

### Capability

Verifiable integrity attestation mechanism for trust establishment.

### Condition

Absence of verifiable integrity evidence or attestation mechanisms.

### Threat

-   **T10.1**: Compromised platform masquerading as trustworthy

-   **T10.2**: Man-in-the-middle attacks on attestation protocols

-   **T10.3**: Replay attacks using old attestation tokens

-   **T10.4**: Attestation bypass through component substitution

### Risk

**HIGH** - Undermines entire trust chain. External systems may trust compromised platforms.

### Requirement

-   **R10.1**: SHALL generate cryptographically signed attestation reports

-   **R10.2a**: SHALL include all security-critical components in attestation

-   **R10.2b**: SHALL support remote attestation verification

-   **R10.3**: SHALL use hardware-backed attestation where available

-   **R10.4a**: SHALL implement attestation freshness mechanisms

-   **R10.4b**: SHALL use mutual authentication for attestation protocols

## 5.11 Administrative Authentication

### Capability

Strong authentication for administrative interfaces and sensitive operations.

### Condition

Missing or weak authentication mechanisms for critical functions.

### Threat

-   **T11.1**: Unauthorized vault access through weak authentication

-   **T11.2**: Privilege escalation via authentication bypass

-   **T11.3**: Session hijacking of administrative sessions

-   **T11.4**: Credential reuse attacks

### Risk

**CRITICAL** - Full control of password manager and all stored secrets. Direct path to complete compromise.

### Requirement

-   **R11.1**: SHALL enforce multi-factor authentication for administrative access

-   **R11.2**: SHALL implement certificate-based authentication option

-   **R11.3**: SHALL enforce session timeout and re-authentication

-   **R11.4a**: SHALL use separate authentication credentials for administrative functions

-   **R11.4b**: SHALL implement account lockout after failed attempts

## 5.12 Access Control

### Capability

Authorization and access control enforcement for functions and data.

### Condition

Missing or weak authorization mechanisms within the password manager.

### Threat

-   **T12.1**: Unauthorized access to shared account credentials

-   **T12.2**: Privilege escalation within the application

-   **T12.3**: Bypassing access controls through API manipulation

-   **T12.4**: Time-of-check to time-of-use (TOCTTOU) vulnerabilities

### Risk

**HIGH** - Enables unauthorized access to credentials beyond intended scope. Breaks compartmentalization.

### Requirement

-   **R12.1**: SHALL implement role-based access control (RBAC)

-   **R12.2a**: SHALL enforce least privilege principle for all operations

-   **R12.2b**: SHALL validate authorization for each sensitive operation

-   **R12.3a**: SHALL support granular permission assignment

-   **R12.3b**: SHALL log all authorization decisions and violations

-   **R12.4**: SHALL implement atomic authorization checks to prevent TOCTTOU

## 5.13 Data Confidentiality

### Capability

Comprehensive encryption for data at rest and in transit.

### Condition

Insufficient encryption enforcement, compromised storage, or inadequate network isolation.

### Threat

-   **T13.1**: Local vault exposure through file system access

-   **T13.2**: Network interception during synchronization

-   **T13.3**: Memory dump exposure of decrypted credentials

-   **T13.4**: Cache and temporary file recovery

### Risk

**CRITICAL** - Direct exposure of all stored credentials. Catastrophic impact on user security.

### Requirement

-   **R13.1**: SHALL encrypt all data at rest using AES-256 or equivalent

-   **R13.2**: SHALL use TLS 1.3 for all network communications

-   **R13.3**: SHALL implement perfect forward secrecy for communications

-   **R13.4a**: SHALL clear sensitive data from memory after use

-   **R13.4b**: SHALL encrypt swap files and hibernation files

-   **R13.4c**: SHALL disable caching of decrypted credentials

## 5.14 Availability Protection

### Capability

Resilience against denial of service and resource exhaustion attacks.

### Condition

Insufficient protection against resource exhaustion or overwhelming request volumes.

### Threat

-   **T14.1**: API flooding causing service unavailability

-   **T14.2**: Resource exhaustion through memory leaks

-   **T14.3**: CPU exhaustion through computational attacks

-   **T14.4**: Storage exhaustion through log flooding

### Risk

**MEDIUM** - Prevents access to credentials when needed. Critical during incident response scenarios.

### Requirement

-   **R14.1**: SHALL implement rate limiting on all interfaces

-   **R14.2a**: SHALL enforce resource quotas per user/session

-   **R14.2b**: SHALL implement automatic resource cleanup

-   **R14.3**: SHALL support graceful degradation under load

-   **R14.4**: SHALL maintain service availability monitoring

## 5.15 Audit Logging

### Capability

Comprehensive security logging with integrity protection.

### Condition

Insufficient logging capabilities or unprotected log storage.

### Threat

-   **T15.1**: Undetected unauthorized access attempts

-   **T15.2**: Log tampering to hide malicious activities

-   **T15.3**: Log deletion to prevent forensic analysis

-   **T15.4**: Log flooding to obscure attacks

### Risk

**MEDIUM** - Prevents detection and investigation of security incidents. Enables persistent threats.

### Requirement

-   **R15.1**: SHALL log all authentication attempts and outcomes

-   **R15.2**: SHALL log all credential access and modifications

-   **R15.3a**: SHALL implement tamper-evident log storage

-   **R15.3b**: SHALL support secure log export and archival

-   **R15.4a**: SHALL implement log retention policies

-   **R15.4b**: SHALL implement log rotation and size limits to prevent flooding

## 5.16 Update Security

### Capability

Secure update and patch management mechanisms.

### Condition

Lack of cryptographic validation or rollback protection for updates.

### Threat

-   **T16.1**: Malicious update injection

-   **T16.2**: Update replay attacks with vulnerable versions

-   **T16.3**: Update corruption causing system instability

-   **T16.4**: Rollback attacks to reintroduce vulnerabilities

### Risk

**HIGH** - Compromises entire system integrity. Enables persistent backdoor installation.

### Requirement

-   **R16.1a**: SHALL cryptographically sign all update packages

-   **R16.1b**: SHALL verify signatures before applying updates

-   **R16.2**: SHALL implement secure rollback mechanisms

-   **R16.3**: SHALL maintain update audit trail

-   **R16.4**: SHALL include version checking to prevent downgrade attacks

## 5.17 Configuration Security

### Capability

Protected configuration management and change control.

### Condition

Insufficient protection of configuration interfaces or files.

### Threat

-   **T17.1**: Unauthorized security setting modifications

-   **T17.2**: Configuration injection attacks

-   **T17.3**: Privilege escalation through configuration manipulation

-   **T17.4**: Configuration drift from secure baseline

### Risk

**HIGH** - Weakens overall security posture. Enables bypass of security controls.

### Requirement

-   **R17.1a**: SHALL protect configuration files with appropriate permissions

-   **R17.1b**: SHALL require authentication for configuration changes

-   **R17.2**: SHALL validate all configuration inputs

-   **R17.3**: SHALL maintain configuration change history

-   **R17.4**: SHALL support configuration integrity monitoring

## 5.18 Secure Defaults

### Capability

Security-by-default configuration and minimal attack surface. [Hard requirement of the Regulation]

### Condition

Product shipped with insecure default settings requiring manual hardening.

### Threat

-   **T18.1**: Default credentials enabling immediate compromise

-   **T18.2**: Unnecessary services exposed by default

-   **T18.3**: Weak cryptographic defaults

-   **T18.4**: Overly permissive default access controls

### Risk

**MEDIUM** - Many deployments never change defaults. Provides easy initial compromise vector.

### Requirement

-   **R18.1a**: SHALL enforce secure defaults without user intervention

-   **R18.1b**: SHALL require password change on first use

-   **R18.2**: SHALL disable unnecessary features by default

-   **R18.3**: SHALL use strongest available cryptography by default

-   **R18.4**: SHALL provide security hardening guide

## 5.19 Time Synchronization

### Capability

Accurate and secure time synchronization for security operations.

### Condition

Unprotected or unreliable time source mechanisms.

### Threat

-   **T19.1**: Log timestamp manipulation hiding attack timeline

-   **T19.2**: Token expiry bypass through time manipulation

-   **T19.3**: Certificate validation bypass via time shifting

-   **T19.4**: Password rotation schedule disruption

### Risk

**MEDIUM** - Undermines time-based security controls. Complicates incident investigation.

### Requirement

-   **R19.1**: SHALL use authenticated NTP or equivalent protocol

-   **R19.2a**: SHALL validate time source authenticity

-   **R19.2b**: SHALL detect and alert on significant time changes

-   **R19.3**: SHALL maintain monotonic clock for security events

-   **R19.4**: SHALL implement time synchronization monitoring

### Capability

| CRA requirement                         | Technical security requirements(s) |

| --------------------------------------- | ---------------------------------- |

| No known exploitable vulnerabilities    | R7.1; R7.4                         |

| Secure design, development, production  |                                    |

| Secure by default configuration         |                                    |

| Secure updates                          |                                    |

| Authentication and access control mechanisms       |                                    |

| Confidentiality protection              |REQ-GR-CONF-001a; REQ-GR-CONF-001b;REQ-GR-CONF-001c                                    |

| No known exploitable vulnerabilities    | R16.1b;	 R16.2;	 R16.4;                      |

| Secure design, development, production  |              R1.1;  R2.2; R8.1a; R8.3a;	 R9.1a; R9.1b;	 R10.1;   |

| Secure by default configuration         | R18.1a; R18.2; R18.3;                                   |

| Secure updates                          |   R16.1a; R16.1b; R16.2; R16.3; R16.4;                                 |

| Authentication and access control mechanisms       |   R1.1; R1.5a; R11.1;  R11.2;	 R11.3;	 R11.4a;	 R12.1;	 R12.2a;	 R12.2b;                                  |

| Confidentiality protection              |       |

| Integrity protection for data and configuration |

| Data minimization                       |                                    |

| Availability protection                 |                                    |