@@ -1473,6 +1473,10 @@ These requirements apply to the product, regardless of the product's use case an
3. a dedicated Identity Management module built into the product.
***AAC_AUTH-2** The product shall not allow for default credentials or keys to be used to identify subjects.
* This requirement does not apply to tailor-made products, where product user requests changes as per CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (b).
* This requirement does not apply to UC-1-HOME, where the initial password is unique between instances of the product, and is provided to the product user in a confidential manner.
***AAC_AUTH-3** The product shall eliminate default credentials by either:
1. generating credentials during the first use; or
2. enforcing mandatory credential creation during the initial setup of a new system user or a managed element.
***AAC_AUTH-3** The product shall use multi‑factor authentication to authenticate system users.
***AAC_AUTH-4** The product shall limit a system user’s session validity duration via a configurable setting that shall initially be limited to a default of, at maximum, one day.
***AAC_AUTH-5** The authorization model shall enforce separation of privileges appropriate to the use case.
@@ -1506,6 +1510,8 @@ These requirements apply to the product, regardless of the product's use case an
9. and validity interval.
***AAC_AUTH-11** The product shall prevent the execution of any privileged action when the authorisation decision is absent, expired, inconsistent with current policy or context, or cannot be recorded as an auditable event, except where the action aims to enable or restore auditability of the product.
> NOTE: **AAC_AUTH-2** applicability exclusion for UC-1-HOME is a nessesary tradeof when RF-ADMIN is high.
### 5.6.1 Machine users
***AAC_MACHINE-1** The product shall provide authentication for machine users such as certificates or tokens with a lifetime that is appropriate to the use case.
@@ -2632,6 +2638,34 @@ Verify that:
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.6.3 AAC_AUTH-3
**Objective:** Subject identification is not relying on pre-determined defaults.
**Preparation:**
1. Study the technical documentation how to interact with the system;
**Activities:**
1. Investigate the product how it is take into use.
2. Take the product in to use for the first time.
**Verdict:**
1. Pass, if the product mechanism doesn't rely on pre-determinted secrets,
2. and the credential creation is forced as part of the first use.
3. Fail otherwise.
**Supporting Evidence:**
* Screenshots, captures, or console outputs confirming the correct authentication with MFA;
* Logs from the authentication and rejection events;
* Metrics output relevant for the activities, if available;
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
### 6.6.3 AAC_AUTH-3
**Objective:** System users are identified with multi-factor authentication.
