The conclusion is reasonable. It is wrong.

The Two Checks and What Each Actually Proves​

Passive authentication verifies data integrity. The Security Object Document on the card contains SHA-256 hashes of the data groups, signed with MAI's Document Signer certificate, verified against the Ministry's CSCA root. If the check passes, you know the data has not been modified since issuance and that MAI signed it.

Active authentication verifies that the chip holds a private key. The server sends a 48-byte challenge, the chip signs it with its authentication private key, the server verifies the signature against the certificate on the card. If the check passes, you know someone with access to a functional chip responded correctly.

The problem is that the two checks are independent. Passive verifies the data. Active verifies the chip. But neither verifies that the data and the chip belong to the same physical card.

The Attack Vector: Split-Proof​

Here is the concrete scenario.

The CAN code is printed on the front of the identity card. Anyone who holds the card for a few seconds can read it — at a queue, at a counter, during a routine check. The CAN is not a secret in the traditional sense; it is an access identifier for the NFC channel.

With the victim's CAN, an attacker can establish a PACE channel with the card and read the ICAO files that do not require a PIN — the SOD and data from the standard applet. This includes the MAI-signed hashes and, depending on configuration, basic data. Passive authentication of this data will pass on any backend.

The attacker now uses their own card for active authentication. They forward the server's challenge to their own chip, receive a valid signature against their own certificate.

A backend that verifies passive and active separately sees two valid chains. It cannot distinguish the attacker from the legitimate holder — because it never verified that the MAI data and the chip that signed the challenge are the same physical object.

Chip Authentication: The Cryptographic Binding Between Data and Chip​

Chip Authentication (CA, standardised in BSI TR-03110) solves exactly this problem.

The card contains in DG14 a public key Q_chip — specific to this chip, covered by the SOD hash signed by MAI. Chip Authentication performs an ECDH exchange between an ephemeral terminal key and Q_chip. Only the chip that holds the corresponding private key d_chip can produce the correct shared secret.

The server recomputes the exchange and compares:

// Server-side verification (Node.js)
const ecdh = crypto.createECDH('brainpoolP256r1');
ecdh.setPrivateKey(Buffer.from(caEphemeralPrivateKey, 'base64'));
const recomputed = ecdh.computeSecret(qChipFromDg14);

if (!recomputed.slice(0, 32).equals(Buffer.from(caSharedSecretX, 'base64'))) {
    throw new Error('CA binding mismatch — split-proof attack detected');
}

If the comparison fails, someone presented the victim's MAI-signed data with their own chip. The attack is detected.

If it passes, the data from the card and the chip that responded to the challenge are cryptographically bound — because Q_chip is signed by MAI in the SOD, and the ECDH confirms that the physical chip holds the corresponding private key.

What Zero Trust Means in the Context of CEI​

A correct CEI authentication flow enforces three conditions simultaneously:

The data is signed by MAI — passive authentication against the CSCA root.

The chip is genuine — active authentication proves the chip can sign a challenge with its own private key.

The data and the chip are the same physical object — Chip Authentication binds Q_chip from DG14 (signed by MAI) to the chip that performed the ECDH.

Without all three, you cannot issue an authentication token with complete cryptographic guarantee. Without CA in particular, a system that verifies passive and active separately has a real, exploitable attack vector — not a theoretical one.

EidKit SSO: Standard OIDC, Zero Trust on CEI​

EidKit SSO is a standard OIDC identity provider — the same protocol as Google Sign-In or GitHub OAuth. Client ID, Client Secret, redirect URI. If you have ever integrated an OAuth provider, you already know everything you need technically.

// JWT received after successful authentication
{
  "sub": "a3f7bc9d...",          // stable pseudonym per person, not the raw CNP
  "name": "CĂTĂLIN TOMA",
  "given_name": "CĂTĂLIN",
  "family_name": "TOMA",
  "birthdate": "1985-03-15",
  "address": {
    "formatted": "Str. Exemplu Nr. 1, Timișoara, Timiș"
  }
}

The data is not self-declared by the user — it comes directly from the CEI chip, verified by MAI. The home address is included, even though it no longer appears printed on the physical card.

The authentication flow implements all three layers: passive + active + Chip Authentication. The server does not issue any token without cryptographic proof that the user holds the physical card, knows the PIN, and that the data presented and the chip are the same object.

One UX detail that simplifies integration: there is no difference between registration and login. The sub in the JWT is a stable, unique pseudonym per person — the first card tap creates the account automatically, with no form, no email, no password.

Integration documentation and the full security overview are available at eidkit.ro/docs.

We write about the Romanian CEI — its capabilities, its integration challenges, and the regulatory context around it. If a topic here is relevant to something you're building, feel free to reach out.

The deadlines are legal, not aspirational. By the end of 2026, every EU Member State must make at least one certified European Digital Identity Wallet available to citizens. By the end of 2027, private companies in regulated sectors are required to accept it. And the sectors that fall under this obligation include, explicitly, banks, payment service providers, insurers, and telecoms.

If you work in any of these domains in Romania, 2026 is the year to understand what this transition involves — not 2027.

What the EUDI Wallet Is, and Its Connection to the Electronic ID Card​

The EUDI Wallet is a standardised mobile app in which citizens can store and present verified identity credentials — their identity card, driving licence, diplomas, professional qualifications, and other attributes. Users control what data they share and with whom, through selective disclosure: you can prove you are over 18 without revealing your exact date of birth, or confirm you are a resident of a Member State without giving your full address.

The connection to the Romanian CEI is direct and intentional. The Director of DGEP, Cătălin Giulescu, has publicly stated that the electronic identity card is "an intermediary" in the digitisation process — the platform on which Romania's EUDI Wallet will be built. The CEI chip, with its MAI-issued digital certificates, is the primary enrollment mechanism for the wallet. Without CEI, there is no Romanian EUDI Wallet.

Romania is already participating in the EUDIW-PACT pilot project coordinated by the French Ministry of the Interior, alongside 24 other Member States. On 17-18 March 2026, cross-border interoperability tests took place in Bucharest in a live environment — working credential exchange between different Member States.

The Timeline, Clearly​

Article 5f(2) of the Regulation is direct: private companies already legally required to use strong user authentication — Strong Customer Authentication — must accept the EUDI Wallet at the user's request, within 36 months of the implementing acts entering into force. The legal basis for SCA in financial services is PSD2. If you are a bank or fintech processing payments, the obligation is certain.

Penalties for non-compliance reach €5 million or 1% of global turnover, whichever is higher.

Why 2026 Is the Year to Act, Not 2027​

There is a common trap in how companies read regulatory deadlines: they see 2027 and plan for 2027. The problem is that an enterprise-level integration does not complete in a few weeks.

Implementation experts estimate that a full integration, from decision to production, takes between 9 and 18 months for a mid-to-large organisation. A bank with legacy systems, procurement processes, internal audit requirements, and well-defined release cycles will be at the upper end of that range, not the lower.

Companies that start in 2027 will go live in 2028 — after the mandatory deadline. Companies that start in 2026 will be ready on time, and will have gained a competitive advantage: they can offer customers EUDI Wallet authentication before it becomes the standard.

Chambers & Partners, in their Romania FinTech analysis, confirm explicitly: in practice, 2026 is the preparatory year to achieve wallet acceptance and adapt onboarding flows for 2027.

What to Prepare, Concretely​

1. Map your identity flows

The first step is not technical — it is a business exercise. Any company under the obligation must identify every point in its products and services where strong authentication or identity verification occurs: KYC onboarding, authentication for significant transactions, contract signing, access to sensitive data. These are the points that must accept EUDI Wallet credentials.

2. Register as a Relying Party

Companies that want to accept the EUDI Wallet must register as a relying party with the competent national authority. Without registration, you cannot request credentials from user wallets. The registration process is not instant — it involves identifying your legal entity, specifying the attributes you intend to access, and the business reasons why you need them.

3. Technical integration

The technical standards for interacting with the EUDI Wallet — OpenID4VP for credential presentation, OpenID4VCI for issuance, SD-JWT for selective disclosure — are established through the implementing acts. Integration means implementing these protocols alongside existing systems, not replacing them.

4. Redesign KYC data flows

The Regulation mandates data minimisation — you may only request the attributes necessary for the given transaction. If you currently have a KYC flow that collects all available data, you will need to redesign it to request selectively only what is needed for each context. This is an architectural change, not just a UI change.

The Situation in Romania: Solid Foundation, Operational Uncertainty​

Romania is not starting from scratch. The CEI is already in national rollout, with over 1.5 million cards issued and a target of 5 million by mid-2026. ROeID exists as a government SSO application. EUDI Wallet interoperability tests have already taken place on Romanian soil.

What is missing is operational clarity for the private sector. A recent Accace report finds that while legal alignment exists through Law 214/2024, many companies lack clarity on short-term practical requirements. Awareness remains limited outside heavily regulated sectors.

There is also an honest nuance to add: at the European level, some Member States may not meet the 2026 deadline for wallet availability, due to the technical complexity and standards still being finalised in parallel. But the 2027 deadline for the private sector is independent of the exact wallet launch timing — the acceptance obligation exists regardless. And in Romania, the CEI is already available and functional as the foundation.

The Connection to Today's Identity Infrastructure​

There is a direct continuity between what is available now and what will be mandatory in 2027. The EUDI Wallet in Romania will be populated with data from the CEI. NFC-based KYC flows that read the CEI chip today are architecturally compatible with what accepting EUDI Wallet credentials will require tomorrow — the same assurance level, the same identity data source, the same MAI certificates in the verification chain.

Companies integrating CEI NFC reading today for onboarding and identity verification are not building a temporary solution. They are building the identity infrastructure they will need in 2027 — with one or two years ahead of the legal obligation.

We write about the Romanian CEI — its capabilities, its integration challenges, and the regulatory context around it. If a topic here is relevant to something you're building, feel free to reach out.

If you have integrated an electronic passport or another chip-based identity document before, you will enter this project with a reasonable set of assumptions. Most of them are partially wrong for the Romanian CEI.

It is not that the ICAO standards do not apply — they do, as a starting point. The problem is that the CEI is a national identity card with country-specific extensions that appear nowhere in complete public documentation. What follows is a map of the terrain based on complete implementations for both Android and iOS, tested against real CEI cards.

What You Already Know — and What Still Applies​

Any ICAO-based electronic identity card uses PACE (Password Authenticated Connection Establishment) to establish a secure channel before any data can be read. The CEI does the same, using the CAN code — 6 digits printed on the front of the card — as the password.

The result of PACE is a Secure Messaging (SM) channel that wraps all subsequent APDU commands. Any command sent raw after the channel is established is rejected by the card — standard behaviour, not specific to the CEI.

Passive authentication works on familiar principles on both platforms: the chip contains a Security Object Document that chains SHA-256 hashes of the data groups up to MAI's CSCA root certificate. The verification looks different depending on the platform, but the principle is the same:

val sod = SODFile(sodRaw.inputStream())
val dsc = sod.docSigningCertificate
val csca = assets.open("csca_romania.der").use {
    CertificateFactory.getInstance("X.509").generateCertificate(it) as X509Certificate
}
dsc.verify(csca.publicKey) // throws if invalid

let sod = try SodVerifier.parse(sodBytes)
guard let dsc = SecCertificateCreateWithData(nil, sod.dscDer as CFData) else { ... }

var trust: SecTrust?
SecTrustCreateWithCertificates(dsc, SecPolicyCreateBasicX509(), &trust)
SecTrustSetAnchorCertificates(trust!, [csca] as CFArray)
SecTrustSetAnchorCertificatesOnly(trust!, true) // do not use the system trust store
var error: CFError?
let trusted = SecTrustEvaluateWithError(trust!, &error)

Passive authentication must always run before trusting any data read from the card. An engineer with ICAO document experience will be comfortable up to this point. This is roughly where the familiar terrain ends.

Where the Assumptions Start to Break​

The Chip Has Four Applets, Not One​

Standard ICAO travel documents have a relatively predictable applet structure. The CEI does not follow the same pattern. The chip contains four applets with distinct roles:

The ESIGN applet exists on the chip and appears in some reference documents. It is not used. Signing goes through GenPKI, via a command different from what you would assume from reading the standards.

Each applet follows its own selection and authentication flow. You do not select an applet and read what you need.

Two Phases, Different Requirements​

Reading data from the CEI splits naturally into two phases:

Phase 1 — CAN only: accesses data available without a PIN — the holder's photo, the digitised handwritten signature, and the data needed for passive authentication. This phase uses the standard ICAO applet.

Phase 2 — CAN + 4-digit PIN: accesses the full personal data from the EDATA applet, including the home address — which is no longer printed on the physical card.

The Order of Operations Before PACE Is Not Documented — and Matters​

What you must do before PACE depends on what you want to do after PACE, and the rules are asymmetric depending on the usage scenario. Phase 1 requires different preparation from Phase 2 and GenPKI. If the preparation is wrong for the given scenario, failures appear at unexpected points with error codes that do not indicate the real problem.

The situation differs between the two platforms for architectural reasons:

// Phase 1: no pre-selection needed — Android stack starts in MF context
isoDep.timeout = 20_000 // default timeout is insufficient for CEI

val paceResult = ps.doPACE(canKey, paceOid, paceParams, null)
val wrapper = paceResult.wrapper
// all commands from here go through the wrapper

// Phase 2: SELECT AID1 before PACE — chip requires AID1 context for EDATA/GenPKI

// Phase 1: iOS connects into ICAO context (ICAO AID is first in Info.plist)
// PACE does not work in ICAO context — SELECT MF before PACE
let selectMF = NFCISO7816APDU(instructionClass: 0x00, instructionCode: 0xA4,
                               p1Parameter: 0x00, p2Parameter: 0x0C,
                               data: Data([0x3F, 0x00]), expectedResponseLength: -1)
_ = try await tag.sendCommand(apdu: selectMF)
// PACE now works — MF context, same as Android

// Phase 2: SELECT AID1 before PACE — same behaviour as Android

The asymmetric pre-PACE preparation behaviour is not documented anywhere — it was discovered by elimination on both platforms.

Data Formats: Where the Romanian Implementation Diverges​

DG1 Is Not MRZ​

This is where code that works perfectly for passports breaks completely, on both platforms. The identity data returned by the EDATA applet is not in the MRZ format that standard ICAO libraries parse — it is in a Romanian implementation-specific ASN.1 format, with correctly encoded diacritics and differently structured fields:

SEQUENCE (0x30)
  [0] (0x80)  lastName     UTF-8  e.g. "TOMA"
  [1] (0x81)  firstName    UTF-8  e.g. "CĂTĂLIN"  (diacritics preserved)
  [2] (0x82)  sex          UTF-8  "M" or "F"
  [3] (0x83)  dateOfBirth  UTF-8  DDMMYYYY
  [4] (0x84)  cnp          UTF-8  13 digits
  [5] (0x85)  nationality  UTF-8  "ROU"

// jMRTD won't help here — Romanian-specific ASN.1 format
val tags = parseContextTags(dg1Bytes) // custom parser
val lastName  = tags[0x80]?.toString(Charsets.UTF_8)
val firstName = tags[0x81]?.toString(Charsets.UTF_8) // diacritics are correct
val cnp       = tags[0x84]?.toString(Charsets.UTF_8)

// no iOS library parses this format
let tags = parseContextTags(dg1Bytes) // custom parser
let lastName  = tags[0x80].flatMap { String(data: $0, encoding: .utf8) }
let firstName = tags[0x81].flatMap { String(data: $0, encoding: .utf8) } // diacritics are correct
let cnp       = tags[0x84].flatMap { String(data: $0, encoding: .utf8) }

The format is not publicly documented — it was determined by direct inspection of bytes returned by the card.

The Two Cryptographic Keys in GenPKI​

GenPKI contains two distinct keys, on different elliptic curves, with different internal signing behaviours:

Confusing them produces an incorrect signature with no error message indicating the cause. The behaviour is identical on Android and iOS — this is a chip constraint, not a platform one.

Things That Break Before You Reach Business Logic​

Security.removeProvider("BC")
Security.insertProviderAt(BouncyCastleProvider(), 1)

PIN counter query does not work in SM mode, on either platform. There is no way to query remaining attempts before sending the actual PIN. You handle SW=63CX in the VERIFY response (X = attempts remaining) and SW=6983 for a blocked card — a detail that directly affects application UX.

We write about the Romanian CEI — its capabilities, its integration challenges, and the regulatory context around it. If a topic here is relevant to something you're building, feel free to reach out.

On 8 October 2024, Romania's Law 214/2024 on the use of electronic signatures entered into force — the most significant piece of legislation in this domain since the country first regulated electronic signatures in 2001. It repealed the old law, clarified the legal framework for all three signature types recognised under European eIDAS regulation, and for the first time gave a clear legal basis to the signature embedded in the new electronic identity card.

Many people read this as a simple announcement: your ID card can now sign documents with legal weight. The reality is more nuanced — and the nuance has immediate practical consequences for anyone building software that involves signed documents, or for individuals trying to understand what their card actually does.

Three Types of Signature, Three Levels of Security​

The law, following the EU's eIDAS Regulation, recognises three types of electronic signature. They are not interchangeable.

Simple Electronic Signature (SES) The most basic level. Examples: typing your name at the end of an email, or attaching a PNG image of your signature to a Word document. The law recognises its legal effect in limited circumstances: acts valued below half the gross minimum wage (~925 RON currently), where the other party acknowledges the document through conduct (for instance, by performing the obligations in it), or where both parties — both legal entities — have agreed in writing in advance to accept this signature type.

Advanced Electronic Signature (AdES) A step up. Must be uniquely linked to the signatory, capable of identifying them, created using data under the signatory's exclusive control, and able to detect any subsequent modification to the signed document. The CEI signature falls into this category — it is created using a certificate issued by the Ministry of Internal Affairs, stored on the card's chip, under the holder's control via PIN.

Qualified Electronic Signature (QES) The highest level. An advanced signature that is additionally created using a qualified signature creation device and based on a qualified certificate issued by a qualified trust service provider (QTSP) — an entity accredited and supervised by the state. Romania has several such providers: certSIGN, DigiSign, CertDigital, Trans Sped and others. The certificate is obtained separately, at cost, usually on a USB token or in the cloud.

The CEI signature is not qualified. It is advanced, with a certificate issued by a public authority — which places it in a subcategory with broader legal effects than an ordinary advanced signature, but still below qualified.

What the CEI Signature Can Do, per Art. 4 of Law 214/2024​

Article 4(5) of the law states that an advanced electronic signature has the same legal effects as a handwritten signature if at least one of the following conditions is met:

a) the act was signed with an advanced electronic signature created with a certificate issued by a Romanian public authority or institution or by a qualified trust service provider

b) the electronic document is acknowledged by the party against whom it is invoked — including through performance of the document's obligations

c) the parties have expressly agreed, in a separate document signed by hand or with a qualified electronic signature, that they will give the advanced signature the legal effects of a handwritten signature

The CEI satisfies condition (a) directly: the certificate is issued by MAI, which is a Romanian public authority. This means that for any act the law requires in written form as a condition of proof (ad probationem), or for which it imposes no particular form, the CEI signature is equivalent to a handwritten signature — with no further conditions required.

Practical examples where it works: service agreements, consultancy contracts, employment contracts (under GEO 36/2021 which explicitly permits AdES for individual employment contracts), official correspondence, administrative applications, commercial agreements between professionals.

What the CEI Signature Cannot Do​

There are two categories where the CEI's advanced signature is not sufficient, regardless of what the law says in theory.

1. Acts Requiring Written Form ad validitatem​

Some legal acts are valid only if they are in written form — not as a condition of proof, but as a condition of validity. Examples: mortgage agreements, donation contracts, articles of association for legal entities. The law says that for these acts, the electronic form is valid if the document is signed with a qualified signature or with an advanced signature that produces the effects of a handwritten signature under the conditions of the law.

The CEI can technically satisfy this condition (MAI certificate = public authority = condition (a) met), but in practice notaries and public registries require a qualified signature. They are within their rights to do so, since the law does not prohibit them from imposing stricter technical requirements in their internal procedures.

2. Automated Government Platforms — the Practical Problem​

ANAF / SPV: As of the date of this post, the ANAF Private Virtual Space does not recognise the CEI signature. Platforms with automated validation check certificates without human intervention and accept only qualified signatures. You can sign a document correctly and legally with your CEI, and the platform will reject it automatically. This applies to: tax declarations D212, D112, D300, and any other filing through SPV.

ONRC: Same situation. Registration of corporate acts, statutory amendments, any legally binding operation at the Trade Registry requires a qualified signature.

SICAP/SEAP: Participation in public procurement requires a qualified signature.

The technical reason: these platforms were built and configured before the CEI existed at national scale. Automated validation accepts only qualified certificates — the only ones with a well-defined structure that can be validated instantly. The CEI's advanced certificate, though legally valid, does not pass through the same technical channel.

An Exception Worth Knowing: Closed Electronic Systems​

Art. 4(5)(d) of the law allows an advanced signature to produce the effects of a handwritten signature within a closed electronic system — a platform used by a defined set of participants, subject to a security audit process. This means a private company can build a signing flow that accepts CEI signatures and give them full legal weight in its internal operations or customer-facing processes, if the system architecture meets the law's conditions.

This is the space where the private sector can and should move faster than the state.

The CEI Certificate: a Few Technical Details​

Law 214/2024 contains a specific provision for the CEI certificate: by way of exception from the general two-year rule for advanced signatures, the certificate issued by MAI and inscribed on the electronic identity card is valid for up to five years (Art. 3(5)). The exact validity is set by MAI at issuance.

The certificate covers the advanced electronic signature. It is not a qualified certificate. If you need a qualified signature for SPV or ONRC, you must obtain a separate certificate from an accredited provider — certSIGN, DigiSign, CertDigital or another on the list approved by the Authority for the Digitalisation of Romania.

Where It Works Well Now: The Private Sector​

If the automated government platforms are the problematic exception, the entire private sector is open territory. The CEI certificate is issued by MAI — a public authority — which means it satisfies condition (a) of Art. 4(5) directly. Any company building a signing flow with the CEI needs no additional conditions: no prior written agreement between parties, no tacit acknowledgement. The signature is valid from the first use.

The domains with the strongest practical potential:

HR and employment contracts. GEO 36/2021 explicitly permits advanced electronic signatures for individual employment contracts and all related HR documents. Companies hiring remotely or processing large volumes of HR paperwork need exactly this — verified identity and a signed contract in the same flow.

Fintech and financial onboarding. Service agreements, mandate documents, consent forms, credit agreements (excluding mortgages which require a notary). A fintech building its onboarding on CEI gets identity verification, domicile address, and a legally valid signature in a single NFC interaction.

Real estate — rental. Lease contracts are ad probationem, not ad validitatem. The CEI's advanced signature is entirely sufficient. Proptech platforms eliminating in-person attendance at lease signings have the legal foundation to do so.

Insurance. Policy contracts, broker mandates, damage claim declarations. The ASF (Financial Supervisory Authority) has actively pushed toward digital workflows. Insurance companies need identity verification at onboarding and a signature on policy documents — the CEI handles both.

Telecommunications. Subscription contracts are standard commercial agreements, fully valid with an advanced signature. Orange, Vodafone, Digi — each currently has massive onboarding friction.

Private healthcare. Consent forms, treatment agreements, admission documents for private clinic networks.

Freelance and B2B collaboration platforms. Collaboration agreements, service contracts between professionals. Under Law 214/2024, B2B contracts between professionals with a prior written agreement are valid with any advanced electronic signature.

Legal services. Client retainer agreements, mandates (împuterniciri), internal document flows for law firms.

Banking — customer-facing contracts. Distinct from the SPV/ANAF problem: banking service contracts with individuals, investment mandate agreements, onboarding documents for new accounts — all of these are private relationships, not interactions with automated government platforms. The CEI signature is valid.

What all these domains have in common: they need verified identity and a signature and they benefit from eliminating friction in their onboarding or signing process. The CEI is the only mechanism available in Romania that delivers all three simultaneously, from a phone, without additional hardware, without a visit to an office.

What Comes Next​

The situation is not fixed. The government has indicated it is working on making state platforms technically compatible with the CEI signature, though no public deadline has been committed to. Pressure is building from several directions: the number of CEI cards in circulation is growing quickly, the eIDAS 2.0 Regulation requires institutions to accept recognised electronic identification means, and the EUDI Wallet — the EU digital identity wallet — must be available in Romania by the end of 2026.

For now, the practical picture is straightforward: the CEI signature works well in private-sector relationships and anywhere a human reviews the document. It does not yet work on automated government platforms.

We write about the Romanian CEI — its capabilities, its integration challenges, and the regulatory context around it. If a topic here is relevant to something you're building, feel free to reach out.

Something quietly changed when Romania rolled out its new electronic identity card — the Carte Electronică de Identitate, or CEI. The home address disappeared from the physical card. No more printed street, number, city, county on the back. That information is now stored exclusively on the chip inside the card, readable only via NFC or a card reader.

In theory, this is an upgrade. The address can be updated electronically when you move, without needing to reissue the card. In practice, it has created a slow-motion crisis that is now visibly breaking down.

The Problem in One Sentence​

Millions of Romanians now carry an ID card that legally contains their home address — but cannot hand it to a bank teller, notary, or civil servant in a way they can read it.

As of this week, the Romanian government has logged over 300 formal complaints in the "Passport and Identity Card" category alone on its fara-hartie.gov.ro platform. The most reported issue by far: the missing printed address. Banks, notaries, schools, ANAF offices, and local authorities are all asking for a separate adeverință de domiciliu — a paper certificate proving the address that is already, technically, on the document they are holding.

One person described arriving at a notary for a property transaction and being turned away because the CEI "was not sufficient to prove domicile." Another went to open a bank account, same story. A 34-year-old recounted: "I got the electronic ID because I understood it was more modern and secure. Nobody told me I'd need a separate certificate every time I have to prove my address."

This is what happens when infrastructure moves before institutions are ready to use it.

What the Government's Fix Looks Like​

To its credit, the government has moved quickly. On March 25, 2026 — two days ago — civil registry offices were instructed to look up applicants' addresses themselves in the national database, rather than conditioning service on a physical document.

Banks have received direct database access to the population registry and, according to the government announcement, no longer need to ask for the certificate.

For notaries, a similar mechanism is being tested.

And for everyone else — citizens who need to show address proof somewhere that doesn't have database access yet — the Ministry of Internal Affairs has launched a mobile app called RoCEIReader. You tap your card, enter the 6-digit CAN code and your 4-digit PIN, and the app reads the address off the chip and lets you save it as a PDF.

It is available for Android. The iOS version is "coming soon."

The Options for Reading the Address​

For anyone building software that needs a verified home address in Romania, the transition has real consequences. The old workflow — ask the user for a scan of their ID card, OCR the address from the back — no longer works. The address is not on the back.

The alternatives, roughly in order of robustness:

Government database lookup Banks have been given direct access to the DGEP population registry. Clean, no NFC required, no user interaction beyond a CNP. Access requires a formal agreement with the government authority and is not available to arbitrary private companies on request.

NFC chip read The card is read directly using the CAN code printed on its front face. This gives you the address as the government has it — cryptographically signed, verifiable against the Ministry's certificate chain, no dependency on a third-party database. The address lives in the card's EDATA applet, behind a PACE secure channel and a 4-digit PIN. Reading it correctly requires handling some Romanian-specific data formats that standard ICAO libraries do not cover out of the box.

User-produced certificate The workaround the government is now facilitating via RoCEIReader. Legally valid. Introduces a manual step for the user, a 6-month validity window on the certificate, and friction at exactly the point where onboarding flows tend to lose people.

The Larger Pattern​

The address issue is the most visible symptom, but the CEI is capable of considerably more than any institution has caught up to yet.

The chip contains biometric data, a face photo, and two cryptographic keys backed by MAI-issued certificates. One key is for advanced electronic signatures — under Law 214/2024, a document signed with this certificate carries the same legal weight as a handwritten signature. The other is for active authentication: a challenge-response proof that the chip is genuine and not cloned.

And yet ANAF's own tax filing platform rejects the CEI's signature. It only accepts signatures from separately purchased qualified certificates sold by commercial providers. The card grants you a legally valid signature. The government's own portal won't accept it.

The card is ahead of the ecosystem. The ecosystem is catching up, institution by institution. Banks have caught up on address verification. Notaries are close. ANAF has not caught up on signatures. The same pattern will repeat for every institution that needs to interact with these cards over the next two to three years.

What Reading the Chip Actually Involves​

For the technically curious: the CEI chip runs the PACE protocol (Password Authenticated Connection Establishment) using AES-256 to establish a secure channel before anything is readable. After the channel is open, reading personal data requires selecting the correct applet, completing PIN verification, and parsing the response in a Romanian-specific ASN.1 format that is not the same as the ICAO MRZ format most libraries expect.

Passive authentication — verifying that the data on the chip is signed by MAI and hasn't been tampered with — should always run before trusting anything read from the card. It chains from the data groups through the document signing certificate up to the Ministry's CSCA root.

None of this is exotic. But it is specific, and the specifics matter. The card is not something you can integrate with by reading the standard ICAO documentation and adapting a passport reader. The Romanian implementation has its own applet structure, its own data formats, and its own sequence requirements that are not publicly documented in a complete way anywhere.

From July 2025, the CEI became the only identity card model being issued nationally. Every identity document issued in Romania from here forward contains a chip the bearer cannot show to most institutions in a form they can read.

That gap will close gradually. The question for anyone building in this space is how long they are willing to wait for it to close, and whether the interim solution — user-produced PDF certificates of what's already on the card — is acceptable friction for their product.

We write about the Romanian CEI — its capabilities, its integration challenges, and the regulatory context around it. If a topic here is relevant to something you're building, feel free to reach out.