The 2026 electronic identification statute did two things at once. It created a digital identity wallet with user-protection rules that are unusually strong and are in force now, and it wrote a set of acceptance obligations — on the state, on regulated businesses and on very large online platforms — that do not operate until Montenegro joins the European Union.
Knowing which half is live is the whole practical question, and the answer is not what the structure of the Act suggests on a first read.
Article numbers below are from the Zakon o elektronskoj identifikaciji i uslugama povjerenja, published in "Službeni list CG" br. 92/2026 of 30 June 2026 and in force since 8 July 2026, read from the promulgated text on 5 September 2026. We set out the signature and trust-service half of the same Act separately, in Montenegro's new e-signature law.
What the wallet provider may not do
Article 16 imposes the obligations on the provider of a digital identity wallet, and four of them are user protections that operate today.
The wallet is free. It is issued, used and revoked free of charge for natural persons. Not discounted, not free at the point of issue — free across the whole lifecycle, including revocation.
The user is in control. The provider must enable the user to have full control over the use of the wallet and over the data contained in it.
Usage may not be tracked beyond necessity. The provider does not collect information about the use of the wallet that is not necessary for providing the wallet services.
Data may not be combined. The provider does not combine personal identification data, or any other personal data stored in or relating to the use of the wallet, with personal data from any other service it provides, or from third-party services that are not necessary for providing the wallet services — unless the user expressly requests it.
Article 16 adds a structural requirement behind those rules: personal data connected with the digital wallet must be kept logically separate from all other data the provider holds. And it requires the provider to make it easy for users to request technical support and report incidents affecting the wallet's use, and provides that the wallet is issued within an electronic identification scheme with a high level of assurance and integrated security.
Read together, this is a no-profiling regime written into the statute rather than into a privacy policy. A provider cannot lawfully build a behavioural picture from wallet usage, and cannot join wallet data to its other products by default.
Who can ask you for what
The Act also regulates the other side of the transaction — the relying party that wants to use the wallet to authenticate you.
Article 20(1) requires a relying party intending to use the digital identity wallet for the purposes of providing electronic services to register. Article 20(2) puts the application to the Ministry on a prescribed form.
Article 20(3) lists what must be supplied, in three groups: the information the wallet needs to authenticate the relying party — the state of registration, the name, and where applicable the registration number and the identification of the official record it comes from; contact details — website, unique official electronic communication address or telephone; and the intended purpose of using the wallet, stating the data the relying party will request from users.
Article 20(4) then supplies the sanction-free but decisive rule: the relying party must not require the user to provide any data other than the data set out in that declaration.
That converts the registration from a formality into a scope limit. What a business told the Ministry it would ask for is the ceiling on what it may ask for.
Article 21 makes that scope public. The relying parties that have supplied the Article 20(3) data are entered in a register of relying parties, containing those data, kept by the Ministry in electronic form suitable for automatic processing, published on the Ministry's website, and signed with an advanced electronic signature or sealed with an advanced electronic seal. Article 22 obliges a registered relying party to notify the Ministry of any change to those data without delay.
So a user asked for more data than they expected can, in principle, check the published register and see what that business declared.
What the wallet is for, and what it is not
It helps to be clear about the object before the obligations, because "wallet" carries a lot of unrelated associations.
Article 16 places the wallet inside an electronic identification scheme with a high level of assurance, with integrated security — that is, it is an identity instrument, issued under the assurance framework the Act establishes, not a payment instrument and not a general document store the provider curates.
Two of the Article 16 duties only make sense in that light. The requirement that the provider enable the user to have full control over the use of the wallet and over the data in it allocates the decision about disclosure to the holder rather than to the provider or the relying party. And the prohibition on combining wallet data with the provider's other services means the wallet cannot become an authentication layer that feeds a wider customer profile — the position an identity product would otherwise drift into commercially.
Article 16 also imports parts of the trust-service regime by reference, applying to the wallet provider the obligations in Article 53(1) point 2 and points 4 to 9, and Article 54(2), of the same Act. Those are the operational and security requirements imposed on qualified trust service providers, so the wallet provider is held to that standard rather than to a lighter one designed for consumer applications.
Finally, the support obligation is not decorative. Article 16 requires the provider to ensure users can easily request technical support and report technical problems or incidents that negatively affect use of the wallet. For an identity instrument that gates access to services, a broken wallet is an access failure, and the Act treats the reporting channel as part of the product.
The acceptance duties — and why none of them applies yet
Article 30 is the cross-border recognition provision, and it contains five paragraphs. The commencement note to the Act defers Article 30 paragraphs (1), (2) and (3) to the date of Montenegro's accession to the European Union. Paragraphs (4) and (5) are not deferred.
| Art. 30 | What it provides | Status |
|---|---|---|
| (1) | Where Montenegro requires electronic identification for access to public-authority e-services, it will accept European digital wallets on the European Commission's certified list | Deferred to accession |
| (2) | Private relying parties — excluding micro and small enterprises — required to use strong user authentication, or contractually required to in transport, energy, banking, financial services, social security, drinking water, postal services, digital infrastructure, education or telecommunications, will accept EU wallets on the user's voluntary request | Deferred to accession |
| (3) | Very large online platform providers that require authentication must accept and facilitate EU digital wallets, on the user's voluntary request, using the minimum data needed for the specific service | Deferred to accession |
| (4) | EU wallets on the Commission's certified list are recognised for identification for access to e-services in Montenegro on the basis of a reciprocity-based international agreement, with implementing acts forming part of it | In force |
| (5) | Wallets on a certified list in a non-EU state are recognised for authentication on the same treaty basis | In force |
The consequence is precise. The three provisions that would create obligations to accept an EU wallet — on the Montenegrin state, on regulated private relying parties and on very large platforms — are dormant. What remains operative is the pair of provisions under which foreign wallets are recognised only where a reciprocity-based international agreement exists.
That is the same architecture the Act uses for trust services, where Article 63(1) is deferred and Article 63(2) leaves recognition to a reciprocity treaty. In both cases the EU-facing machinery is enacted and switched off, and the operative route runs through an agreement that has to be identified rather than assumed. We have not identified a published agreement of that kind for wallets, and we are not going to assert either that one exists or that none does — it is a question for the Ministry in respect of the specific wallet and service concerned.
What this means for a business, and for a user
For a business planning to use wallet-based authentication in Montenegro, the sequence is: register as a relying party under Article 20 before using the wallet; declare the intended purpose and the specific data you will request, because Article 20(4) makes that declaration your limit; expect the declaration to be public under Article 21; and update it without delay under Article 22 when it changes. Do not build a product assumption on EU wallet interoperability, because Article 30(1) to (3) are not in force.
For a user, the Article 16 protections are the ones worth knowing: the wallet costs nothing at any stage of its life, the provider may not track usage beyond necessity, may not combine wallet data with its other services without your express request, and must keep the data logically separate. If a relying party asks for more than it needs, the register under Article 21 is the place to check what it said it would ask for.
Before you build the integration
If you are designing an authentication flow, a customer onboarding process or a public-facing service that will rely on Montenegrin electronic identification, send us the data you intend to request, the services it will support and the jurisdictions your users will be in, and we will identify what the Article 20(3) declaration has to contain, what Article 20(4) then locks in, and where Article 30's deferred paragraphs leave your cross-border assumptions. The signature and trust-service layer of the same Act is in Montenegro's new e-signature law, the contract layer for technology supply in the four clauses in your SaaS contract, the data-transfer layer in cross-border data transfers, and how we run technology files sits with our IT law practice.
