How Is Access Controlled in Passport Software?

Access control in software is the system that decides which actor can see, introduce, modify or update each passport field, based on the access rights in Annex XIII and the implementing act under Article 77. Article 78 requires that access, introduction, modification and updating rights be restricted based on those access rights, and that passport data remain available after the responsible operator ceases to exist or ceases activity in the Union. Access control is therefore a legal control implemented in software, not a general IT permission setting, and it must be designed field by field.

Access failure takes two forms, and both are serious. Overly broad access discloses restricted data to actors who should not hold it, including commercial detail and test evidence. Overly narrow access withholds dismantling, safety or authority information from actors who need it to act safely and lawfully. A system that grants access by role alone, without field level tier control, will fail in one direction or the other for at least some fields. Field level control, tied to Annex XIII tiers, is the design that the Regulation requires.

What access tiers apply to passport data?

Access tiers in Annex XIII separate public information, information for persons with a legitimate interest, and information for notified bodies and market surveillance authorities, with a further point for information that is accessible to the Commission and other specified actors where provided. Each Annex XIII field is assigned to a tier, and the software must enforce that assignment for reading, and must enforce the separate rights for introducing, modifying and updating information. A field assigned to the authority tier must not be readable through the public route, and a field assigned to the public tier must not require authentication that the public cannot obtain.

A tier map should list every Annex XIII field, its tier, its read rights, its update rights and its source. A map that lists roles without fields cannot be tested, and a map that lists fields without update rights cannot control modification. The map should be version controlled against the Annex XIII and implementing act versions in force, and it should be reviewed after each act change. The map is part of the passport evidence, and it should be available to an authority on request.

How is legitimate interest established in software?

Legitimate interest in software is established through an authentication and authorisation process that verifies the actor identity, the actor role, and the interest basis for the specific battery and field requested. A repairer, recycler, repurposer or remanufacturer with a legitimate interest in a battery must be verified as holding that role for that battery, not merely as holding a general account in the system. The verification should be recorded, with the actor, the role, the battery identifier, the fields accessed and the time, so that access can be audited.

Worked check: a repairer requests dismantling information for a battery. The system verifies the repairer role, the battery identifier and the field tier, and grants the dismantling fields for that battery only. A second request from the same account for a different battery, without a verified interest in that battery, is denied or held for verification. A system that grants all dismantling fields for all batteries on the basis of a single account login fails the per battery interest test.

How are update rights controlled?

Update rights are controlled separately from read rights, because an actor who may read a field may not be authorised to update it. The responsible operator, or an operator authorised to act on behalf of the responsible operator, holds update rights for the fields that the operator is responsible for, subject to the implementing act rules for introducing, modifying and updating information. A supplier who provides data for a field does not thereby gain a right to update the passport field directly, unless the implementing rules and the operator authorisation provide for it. Supplier data should flow through a controlled update process, with verification by the responsible operator.

Update control should include authentication, authorisation, change recording and, where required, approval before publication. A direct database edit that bypasses the update process creates a change without a trail, and it cannot be audited. A controlled update that records the actor, the field, the old and new values, the reason and the approval, where required, creates a trail that an authority can follow. The trail should be immutable for the change record itself, even when the field value is later changed again.

What happens when an operator ceases activity?

When the responsible operator ceases to exist or ceases activity in the Union, the passport must remain available, as required by Article 78. Software design must therefore include a continuity arrangement, such as a successor operator, an escrow or hosting arrangement, or a transfer to an authorised operator, that keeps the passport resolvable and updatable under the tier rules. A hosting arrangement that ends when the operator ceases activity, without a successor, fails the continuity requirement, even when the passport was available during the operator lifetime.

Continuity planning should be documented before it is needed, with the successor or escrow arrangement named, the trigger defined, and the transfer test carried out. A plan that names a successor without a test is an assumption. A plan with a test, in which the successor system resolves a sample passport and applies the tier rules, is evidence. The plan should be reviewed when the hosting arrangement changes, when the operator structure changes, or at least annually, with the review dated.

How are access decisions audited?

Access decisions are audited through access logs that record the actor, the role verification, the battery identifier, the fields requested, the decision, and the time, for both granted and denied requests. Logs must be protected from alteration, retained for the period required, and available to an authority on request. A log that records only successful accesses cannot show whether denied accesses were correctly denied, and a log that records only failures cannot show the pattern of legitimate access. Both outcomes are needed for a complete audit picture.

Log review should be a periodic control, with a sample of granted and denied accesses checked against the tier map and the interest verification. A log that is never reviewed will accumulate errors without detection, including a role that retains access after the role ends, or a field that is accessible through a route that bypasses the tier check. Review findings should be recorded, with corrections and process changes, and the review should be dated.

What access claims should be avoided?

Access claims should avoid stating that a system is secure because it requires a login, that a system is compliant because it uses role based access, or that a system protects data because it encrypts data at rest. Each claim needs a field level test: a tier test for access, a per battery interest test for legitimate interest, and an update trail test for modification control. As checked on 28 October 2026, the detailed access rules depend in part on the implementing act under Article 77, so access design should carry a review date tied to that act. This guide gives general educational information only and is not individual legal advice. A reader with a specific battery or market decision should check the current Regulation text and any applicable delegated act, as checked on 28 October 2026, before acting.

This guide gives general educational information only and is not individual legal advice. A reader with a specific battery or market decision should check the current Regulation text and any applicable delegated act, as checked on 28 October 2026, before acting. Access is a field level legal control, and the tier map should be tested for both granted and denied requests.