Annex I Part I (2)(d) unauthorized access: CRA evidence

What Annex I (2)(d) asks products to do before they reach the market

Annex I Part I point (2)(d) asks the manufacturer to make sure the product is protected from unauthorized access through appropriate control mechanisms, such as authentication and identity or access management, and that the product can report possible unauthorized access. For a product team or compliance lead, the practical question is whether every route into the product, including the administrative console, the APIs, service accounts and maintenance interfaces, is covered by a defined control, and whether an attempt to get past that control leaves a trace the product can surface. Under Article 13(2) the manufacturer decides what counts as appropriate by analyzing the product's cybersecurity risk assessment, and the technical documentation must then explain how the control is implemented or justify why a given element does not apply (Article 13(3) and (4)). Confirm early which accounts, interfaces and integrations the risk assessment has identified, because the documentation will be judged against that list.

The difficulty is that access control is rarely missing from the main login page. It is usually missing from the places the main login does not reach: default or factory accounts that ship with known credentials, administrative interfaces exposed on a second port or path, service-to-service integrations that authenticate with a shared secret, and recovery or debug paths that skip multi-factor checks. A review should inventory each of these against the risk assessment and record either the control applied or the reason it is out of scope. If the product is an identity or access management component, or its core function is access control, the bar is higher: identity management systems and privileged access management products are themselves class I important products under Annex III point 1, which brings a notified body into the conformity route.

Visibility is the second half of the point, and it is the part teams most often leave to a later release. The product should record failed and successful authentication, changes to privileges, and access to sensitive functions in a form an operator can review, and the risk assessment should state which events are logged and how long they are kept. Open-source identity providers such as authentik, Keycloak and Zitadel offer multi-factor options and audit features that can support this design, but each product's default settings and event coverage must be confirmed against the specific deployment in the Zitadel default settings documentation and the vendor documentation for the version in use.

Which systems, accounts and teams fall under the access control duty

Point (2)(d) applies to every route by which someone or something can reach the product, not only the login screen. The cards below cover the access paths, the teams that own them and the scoping choice that changes the conformity route.

User-facing sign-in

Customer and end-user logins are the most visible access path, covering passwords, sign-up flows, password recovery and any federated sign-in. Check every route that establishes a session, including mobile apps, APIs that accept user tokens and account recovery paths that bypass the main login. Record which of these the risk assessment treats as in scope and how each one is protected against unauthorized access.

Administrative and maintenance interfaces

Admin consoles, diagnostic pages, configuration portals and remote maintenance tools carry the highest privilege and are often overlooked in scoping. Confirm whether each interface is reachable from the network, which roles can use it and whether privileged actions require stronger authentication than standard user sessions. Support staff access to these interfaces belongs in the same inventory.

Service accounts and API keys

Machine identities such as service accounts, integration tokens and API keys authenticate without a person present, so they are easy to leave outside the access review. List every credential the product issues or consumes, who owns it, where it is stored and how it is rotated or revoked. A key that cannot be traced to an owner is a finding the assessor will raise.

Device and local console access

Physical and local paths include serial consoles, debug ports, local setup wizards and recovery modes on hardware or on-premises installs. Determine which of these remain enabled in shipped configurations, whether they demand authentication and whether local access is logged. For devices in the field, the scope decision should state how access is controlled when the device is not connected to a network.

Third-party identity providers

Many products delegate sign-in to an external identity provider, directory or single sign-on service that the manufacturer does not operate. Document each dependency, the protocol used, what happens to the product if that provider fails and which party is responsible for its configuration. Confirm the contractual and technical boundaries with each provider before relying on it as an access control.

Access control products change the route

If the core function of the product is identity management, privileged access management or access control readers, it falls under Annex III point 1 as a class I important product. That classification means stricter conformity assessment than the default self-assessment route, so confirm the product category early. Ask the team whether the product's main purpose is access control before the scope is set.

What counts as an appropriate control mechanism and a credible report

Point (2)(d) does not name a technology, so the test is whether the mechanisms a manufacturer chose fit the threats in its Article 13(2) risk assessment. An authentication design is appropriate when each mechanism answers a threat the assessment identified. Password-only sign-in may be enough for a low-exposure internal tool, but it rarely answers credential stuffing or phishing against an internet-facing administrative console. For those threats, the decision should cover authentication strength, multi-factor options (TOTP apps, U2F or passkeys, and one-time codes sent by email or SMS, which carry different resistance to interception), identity lifecycle controls such as deprovisioning when someone leaves, session timeouts and re-authentication for sensitive actions, and separation of privileged accounts from everyday ones. Each choice should be traceable to a named threat, not to a default.

The reporting half of the requirement asks whether the product surfaces possible unauthorized access in a form operators can act on. Failed-login records, account lockout events, new-device sign-ins, privilege grants and changes to authentication policy are the usual candidates. Confirm in your own testing that these events are written with a timestamp, the account and source identifiers, and the outcome, and that they reach a log destination the customer controls. Check whether the product can raise an alert or whether it only writes a record, because the requirement concerns reporting that someone can use.

If the product does not use a mechanism the risk assessment might suggest, a documented justification is acceptable only if the technical documentation under Article 13 records it. The justification should state the threat, why the mechanism does not apply in the product's deployment model, and what compensating control is in place. An unexplained absence reads as an omission to a market surveillance authority, and a justification that is not written down at release cannot be produced later as evidence of conformity.

How an assessor tests access control and unauthorized access reporting

This table compares what an assessor checks for each part of the (2)(d) duty, what evidence they ask to see, and where products most often fall short. Read each row as a test question: if the evidence in the middle column cannot be produced, the finding in the right column is the likely outcome.

Test area	Test approach and evidence requested	Common findings
Risk assessment link	Confirm the Article 13 risk assessment identifies unauthorized access as a threat, records how (2)(d) applies, and ties each access control to a named risk. Request the risk register entries and the technical documentation section that explains implementation.	Access controls exist but the risk assessment never mentions them, or the documentation gives no justification for mechanisms that were not applied.
Authentication design	Walk through the sign-in flow for every user type and interface. Request architecture diagrams, configuration exports and a list of supported authentication methods.	Authentication handled differently across web, API and local console paths, with one path left weaker than the others.
Identity and privileged access management	Review how accounts are created, approved, changed and removed, and how administrator rights are granted and reviewed. Request role definitions and a sample of access approvals.	Undocumented default accounts or shared administrator credentials still present in shipped builds or installation guides.
Multi-factor coverage	Check which accounts and interfaces require a second factor, and whether administrator and remote interfaces are included. Request the policy settings and a coverage matrix.	Administrator interfaces without a second factor, or MFA enforced only for some user groups without a recorded reason.
Session and credential handling	Test session timeouts, token lifetimes, password or key storage, and reset flows. Request configuration values and the design notes for credential storage.	Long-lived tokens, sessions that survive password changes, or credentials stored in plain text in configuration files.
Detection of unauthorized access attempts	Trigger failed logins and privilege escalation in a test environment, then confirm the product records them and makes them visible. Request sample log entries and the alerting configuration.	Logs that record nothing an operator can use, such as missing user identifiers, timestamps or source addresses.
Reporting to the operator	Confirm the product reports possible unauthorized access to the operator through an alert, log export or documented notification path. Request the runbook and an example report.	Reporting exists only as a debug log, with no documented way for an operator to receive or act on it.
Documented justification for mechanisms not applied	Check that each access control the product does not implement has a written reason tied to the risk assessment. Request the justification records and their review dates.	Gaps are left undocumented, so the assessor cannot tell whether they were decided or simply overlooked.

How to implement the access control and reporting duty, step by step

This sequence turns the point (2)(d) requirement into a documented set of access paths, matched authentication mechanisms, tested controls and a working route for reporting unauthorized access, so each decision can be traced back to the risk assessment.

Inventory every access path to the product
Start from the Article 13(2) risk assessment and list each way a person, service or device can reach the product: administrative consoles, user sign-in, APIs, service accounts, maintenance ports, update channels and any remote support access. The product team owns this list, and the security lead reviews it against the architecture diagrams. The step is complete when every path has an owner, a trust level and a note on who may use it. Paths that the team decides not to expose should be recorded with the reason, because the technical documentation must explain how the requirement is met or why a part of it does not apply.
Select authentication and identity mechanisms per path
Match each access path to an authentication method and an identity source, such as a central identity provider, a directory service for Linux and UNIX environments, or local accounts where no central source is feasible. Record the choice in a mechanism decision record that states the path, the chosen mechanism, the rejected options and the risk the choice addresses. Confirm with the vendor or your own environment which protocols each candidate supports, for example OAuth2 and OpenID Connect, SAML, LDAP or Kerberos. Products whose core function is identity or access control fall under stricter conformity assessment, so the decision record should note that classification early.
Configure multi-factor and privileged access separation
Enable second factors for every path that the risk assessment rates as sensitive, and separate privileged roles from ordinary user roles so administrators do not use everyday accounts for administrative tasks. Options commonly include TOTP apps, passkeys, U2F security keys and one-time codes, and some platforms can force every user, or only locally authenticated users, to register a second factor. The output is a configuration baseline that lists the settings, role mappings and session rules as code or exported configuration. Review the baseline with the engineer who owns each setting, and store it under version control so later changes are visible.
Remove or lock default and shared accounts
Find every default credential, factory account, shared login and dormant service account in the product and its installation scripts. Remove those that are not needed, rotate those that must remain, and lock those that exist only for vendor setup. The check is a scripted scan of the built image or deployment template, with results saved as an account inventory that names an owner for each remaining account. Any shared account that cannot be removed should be recorded as a documented exception with compensating controls, since the assessor will look for individual accountability.
Build the unauthorized access reporting path
The point (2)(d) requirement also asks the product to report possible unauthorized access, so define which events count as signals, such as repeated failed sign-ins, new privilege grants, sign-ins from unexpected locations and disabled second factors. Route those events into the logging pipeline and define who receives alerts and how the customer sees them. Coordinate this step with the security logging requirement in point (2)(l), since the two share event sources. The output is a signal catalog with alert owners, a sample alert and a note of where the customer can review events.
Test the access controls and reporting
Run a test plan that attempts to bypass each authentication mechanism, reuse default or shared credentials, escalate privileges and trigger each reporting signal. Testers should include someone outside the build team where possible, and this can be a DeployOpen security testing engagement scoped in writing. The closing output is a test report that lists each case, the expected and observed result, the fix applied and the retest outcome. Only the organization owns the conclusion that the controls work, and an independent assessor reviews the evidence rather than the report alone.
Write the access control technical documentation
Assemble the technical documentation section for point (2)(d) from the earlier outputs: the access path inventory, the mechanism decision record, the configuration baseline, the account inventory, the signal catalog and the test report. For each path, state how the requirement is implemented or why a part does not apply, as Article 13 requires. Confirm the final wording with legal or compliance reviewers, and keep the documentation current through the support period whenever an access path or mechanism changes.

Which evidence passes an access control review and how to keep it current

An assessor testing point (2)(d) looks for a traceable chain from the risk assessment to the access paths, identity design, enforcement settings and test results that show those paths hold. The cards below cover the artifacts that make that chain visible, and the routine that keeps each one accurate between assessments. The manufacturer owns and maintains this evidence, and an independent assessor decides whether it passes.

Access path inventory tied to the risk assessment

This is the list of every route into the product: user interfaces, administrative consoles, APIs, service accounts, support tooling and any remote maintenance channel. Each entry should cite the Article 13(2) risk assessment entry that justified its control, so an assessor can see why the path exists and how it is protected. Rebuild the inventory from the deployed configuration at each release, not from the design document, because undocumented routes are the most common gap. Ask whether any path lacks a risk assessment reference.

Authentication and identity design with configuration exports

Document which identity provider issues credentials, how applications delegate sign-in, and which protocols carry the traffic, such as OpenID Connect, SAML or LDAP. Export the realm, provider or policy configuration as files and store them under version control, so the state at any release date can be shown. Where a product is itself an identity provider, it falls under the stricter class I important route, so state that classification clearly in the design record. Confirm that exported configurations contain no plaintext secrets before they are shared with an assessor.

Multi-factor enforcement settings

Capture the policy that forces a second factor, not only the fact that a second factor exists. Record which users or account types must enroll, whether local accounts are treated differently from federated ones, and which factor types are allowed, such as TOTP, passkeys, security keys or one-time codes by email or SMS. Keep a dated screenshot or export for each release, and test that a user without a second factor cannot complete sign-in. Ask the assessor which factor types they consider acceptable for your risk profile before you finalize the policy.

Role and privileged access records

Maintain a register of roles, the permissions each role grants, and every account holding administrative or privileged rights. Each privileged grant needs a named owner, a documented business reason and an approval record. Review the list on a fixed schedule, removing accounts for departed staff, expired contractors and unused service identities, and keep the signed review record as evidence. Assessors commonly check whether privileged access is separated from routine daily accounts, so show that separation explicitly.

Login and authorization test results

Keep test cases for every login path, token issuance, session expiry, password reset and authorization decision, with the result and the build version tested. Include negative cases such as expired tokens, disabled accounts and attempts to reach administrative functions with a standard role. Rerun the full suite after each release and after any change to identity configuration, then archive the output. Where failures were found and fixed, retain both the failing and passing runs so the remediation history is visible.

Unauthorized access reports and operator responses

Point (2)(d) also requires the product to report possible unauthorized access, so keep samples of the alerts it generates, such as repeated failed logins, privilege escalation attempts or unusual administrative activity. For each sample, record how the operator received the alert, what they did, and when they did it. Confirm that these records exist in production logs before an assessment, because a reporting capability that has never fired in a test environment is hard to demonstrate. Review alert thresholds against the risk assessment at least once a year.

What meeting the access control duty costs in money and effort

The table lists each cost component of meeting point (2)(d), who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for building a written quote. The main takeaway is that open-source identity software removes license spend, but integration, testing and evidence work remain.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Identity and access tooling	Software vendors, or no license fee for self-hosted open source	Licenses recur if commercial. Open-source platforms still need hosting, which recurs	Number of user populations and whether privileged access management is added. Reusing one identity provider keeps it down
Integration and configuration engineering	Implementation partner or internal platform engineers	One-time for initial setup, recurring for each new application or identity source	Count of applications, third-party identity sources and protocols such as OIDC, SAML or LDAP. Standard connectors keep it down
Custom authorization logic	Internal developers or implementation partner	One-time build, plus recurring maintenance with each release	Degree of fine-grained or attribute-based rules. Keeping policy in declarative, reviewable configuration keeps it down
Authentication and authorization testing	Internal QA, security engineers or testing partner	Recurring with each release and after authorization changes	Number of roles, tenants and multi-factor paths to exercise. Automated regression tests in the pipeline keep it down
Unauthorized access reporting and alerting	Internal security operations or managed monitoring provider	Recurring for alert tuning, review and on-call coverage	Volume of failed logins, lockout rules and log destinations. Clear alert thresholds agreed in the risk assessment keep it down
Evidence upkeep	Internal compliance and engineering staff	Recurring across the support period	Number of release artifacts and configuration exports to retain. Generating evidence from the release pipeline keeps it down
External penetration test or review	Independent testing firm	Recurring, usually tied to major releases or changes to access paths	Scope of applications, APIs and admin interfaces. A fixed written scope makes the quote comparable
Assessor sampling time (notified body)	Notified body, when one is required	Recurring at assessment, with re-assessment for significant changes	Number of identity configurations the assessor samples and the completeness of technical documentation. Ask the body for its fee basis in writing

Which self-hosted open-source identity tools can support this evidence

Each tool below covers a different part of the access control story: sign-in federation, Linux directory single sign-on, multi-factor methods, and enforced second factors. Pick based on which applications, users and login paths your product exposes, then confirm each capability against the exact version you deploy.

authentik for federated sign-in

authentik acts as an identity provider that applications delegate sign-in to, using OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. For point (2)(d), the useful evidence is the provider and application configuration export, which shows which products rely on central authentication and which endpoints remain outside it. Check whether every externally reachable interface of your product is bound to a provider, and confirm which protocols your version supports. The MIT license places few obligations on a product maker who embeds or operates it.

FreeIPA for Linux and UNIX access

FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos key distribution center. It fits products that ship or run on Linux hosts where administrator and service access must tie back to a central identity store. The evidence it can produce includes Kerberos ticket policies and host access records that show who could reach a system. Its GPL-3.0-or-later license matters if you distribute modified FreeIPA components inside your product, because copyleft duties follow distribution, so have counsel review the packaging model.

Keycloak for passkeys and OTP policy

Keycloak supports two-factor authentication with passkeys, recovery codes, and TOTP or HOTP codes from common authenticator apps, along with configurable one-time password policies and W3C WebAuthn settings. For point (2)(d), the evidence is the realm configuration showing required authentication flows, OTP policy values and WebAuthn settings, plus recovery code handling. Confirm which credential types are enabled by default in your release and whether recovery procedures meet your risk assessment. Its Apache-2.0 license is permissive and generally simple for a product maker to embed.

Zitadel for enforced second factors

Zitadel login policies support TOTP authenticator apps, U2F security keys, passkeys and one-time passwords sent by email or SMS. Its Force MFA setting can require every user, or only locally authenticated users, to register a second factor. The evidence to keep is the exported login policy showing Force MFA scope, plus login and factor registration logs for the period under review. Its AGPL-3.0-only license is the caveat to weigh: if you modify Zitadel and let users interact with it over a network, you may owe those users the modified source, so decide whether to run it unmodified or obtain a commercial license.

Who does the access control work, and what an auditor will not do for you

Your organization remains the manufacturer. The regulation places the duty to meet the essential requirements on you, so the decisions about how your product controls access stay with your team, even when outside people do the configuration. Your risk assessment under Article 13 must establish what unauthorized access means for your product, and your technical documentation must explain how point (2)(d) is implemented or why it does not apply.

Risk decisions: Decide which access threats the product faces, which mechanisms answer them, and which parts of the point (2)(d) requirement do not apply, with reasons recorded.
Access design: Own the model for user roles, administrator accounts, service identities and default credentials, including how the product behaves before a customer changes anything.
Vendor and component choices: Approve any identity provider or access library your product depends on, and track its support status for the whole support period.
Notification duties: Define who receives reports of possible unauthorized access and who decides what happens next.
Declarations: Sign the EU declaration of conformity and keep the technical documentation current.

Before engaging anyone, confirm that a named owner can explain each access decision without reading the vendor documentation.

What buyers ask about access control costs, effort and outside help

How much effort does Annex I point (2)(d) take to meet?

The effort depends on how much of your product's core function is access control and how many authentication paths it has. The requirement asks for appropriate control mechanisms against unauthorized access, such as authentication and identity or access management, plus the ability to report possible unauthorized access. Effort usually splits into three parts: designing the access model, implementing and testing the controls, and writing the technical documentation that explains how the point is implemented or why it does not apply. A product with a single admin login and no external users is a very different job from a multi-tenant platform with federated sign-in. No effort figure is supplied for this point, so ask any partner for a written breakdown by these three parts before accepting a number.

Can our own engineers handle the access control work in-house?

Often yes, provided the team has real experience with authentication protocols, session handling and privileged access. Your engineers would own the design decisions, the product code and the evidence that the controls work. Outside help is most useful where the team lacks that background, where the risk assessment under Article 13 needs an independent challenge, or where testing needs a second pair of eyes. Under the regulation, the manufacturer owns its controls and remains responsible for the conformity declaration, so in-house ownership is always required even when a partner prepares systems and evidence.

What does the work need from our engineers and product owners?

Expect engineering time on authentication flows, role and permission models, logging of access attempts and the reporting path for suspected unauthorized access. Product owners need to define which user types exist, which actions are privileged and which functions must stay reachable without sign-in. Security engineers should review the risk assessment entries for this point and confirm how each control was tested. Ask a partner to list these roles in the written scope so the internal time commitment is visible before work starts.

Does an identity product need a notified body for conformity assessment?

Possibly, and this is a point to confirm early. Identity management systems and privileged access management software and hardware, including authentication and access control readers, are listed as class I important products under Annex III point 1. For those products, a notified body is needed where harmonized standards, common specifications or certification schemes are not applied in full. Products whose core function is access control therefore face a stricter conformity route than most software. Check the current Annex III wording and the Commission guidance before deciding your route, and do not assume self-assessment applies.

How long will the access control work take?

Timing depends on scope, product architecture and how many access paths the product has, so no fixed duration applies to every product. The reliable source for a timeline is a written plan that the partner and your team agree before work starts, with milestones for design, implementation, testing and documentation. Ask for dependencies that could extend the timeline, such as identity provider decisions, integration with your existing directory, and any notified body review. Be cautious of any timeline quoted before the scope is written down.

Does open-source identity software satisfy this point on its own?

No single product satisfies the point on its own. Open-source identity platforms can supply strong building blocks, such as authentik for OAuth2, OpenID Connect, SAML, LDAP and proxy-based sign-in, FreeIPA for single sign-on in Linux and UNIX environments, Keycloak for two-factor authentication with passkeys and one-time passwords, and Zitadel for login policies with Force MFA. The manufacturer still has to show that the chosen mechanisms fit the risk assessment, are configured correctly in the product, and are tested. Confirm the exact capabilities and licences of each component with its project documentation and your legal team, since licence terms affect how you distribute the product.

What should we ask a partner for in a quote for this point?

Ask for a written scope that names the access paths, user types and privileged functions in your product, the identity components to be used, and the controls to be built or configured. The quote should list deliverables, including configuration, tests, logging and reporting design, and the technical documentation section that explains how the point is implemented or why it does not apply. Confirm who performs each task, what evidence is handed over, and which items are one-time versus recurring, such as updates or retesting after changes. Also confirm that the partner prepares evidence but does not issue reports or certificates, which only an independent auditor, assessor or certification body does. DeployOpen plans and implements this work under a written, fixed scope, and it does not publish a price list, so a quote follows from that scope.

How DeployOpen scopes and implements access control for your product

DeployOpen plans, implements and documents the access control mechanisms that Annex I Part I (2)(d) calls for, working inside your own infrastructure on the self-hosted open-source identity platforms you select. We prepare the systems and technical documentation, while your organization owns the risk assessment, the conformity decisions and the declaration.

How we scope

We agree a written scope listing the product interfaces, user roles and identity flows that the (2)(d) decision covers.
We map the Article 13 risk assessment findings for unauthorized access to specific authentication and authorization configurations.
We confirm with you whether your product is class I important under Annex III, because identity and access control products face stricter conformity routes.

How we build

We deploy the chosen identity provider, such as authentik, Keycloak, Zitadel or FreeIPA, inside your cloud account, data center or air-gapped network.
We configure multi-factor authentication, password and session policies, and role-based access for each application that delegates sign-in.
We set up logging of failed and suspicious sign-in attempts so the product can report possible unauthorized access as the requirement expects.

How we hand over

We test the access controls against the scope, including bypass attempts, and record the results for your assessor.
We deliver technical documentation explaining how each access control is implemented, or why a control does not apply, for your records.
We transfer administration, configuration files and runbooks to your team so the controls remain operable after handover.

How we support

Ongoing support, upgrades and continuous testing of the access controls are available as a retainer under a separate written agreement.
We can review identity platform updates and vulnerability notices that affect the access controls across the support period.
Confirm with us in the quote which evidence we prepare and which parts your independent assessor or notified body reviews.