Quick answer: eIDAS 2.0 — the EU's revision of its electronic identification and trust services regulation — is expanding the trust-services catalogue beyond signatures and certificates, with digital identity wallets and verification schemes moving from the edge case into a regulated mainstream. For a CPaaS buyer, the question that matters is narrower than the regulation: does any of this change how a one-time passcode gets verified over SMS? The honest answer is that platform-level OTP delivery and verification — the codes your API issues, checks, and reports on — stay a tenant-owned control layer, exactly as they did before eIDAS 2.0 landed. What changes is the vocabulary: regulated markets now have more ways to name "who proved whom," and the number-lookup and OTP checks you already run are the verification layer those names intersect with. This post reads the regulation in plain words, maps it to the verification surfaces Devotel Orbit ships, and draws the line between identity-proofing (what eIDAS governs) and KYC document collection (what it does not).
This is a buyer-facing explainer in the same family as the ITU-T party-determination post and the SMS-pumping fraud explainer — timed news desk, not a product announcement: a regulation your OTP posture will eventually be asked about, plus the tenant-owned controls you can set while the transposition timelines run.
What eIDAS 2.0 actually says
The original eIDAS regulation (2014) created the EU-wide legal frame for electronic identification, signatures, and trust services. The 2.0 revision broadens the toolkit:
- Digital identity wallets. A member-state-approved wallet on a citizen's device, holding verified attributes, usable for both public-sector and private-sector services. "Verify with the wallet" becomes a third rail beside "share a document copy" and "receive an SMS OTP."
- An enlarged trust-services catalogue. Beyond signatures and seals, the revision formalizes (among others) electronic timestamps, archiving, and remote verification — the plumbing a regulated identity scheme rides on.
- Qualified attribution of data. A standard way to say "this attribute (name, address, phone number) was verified to a regulated bar" and for a relying party to consume it.
Two things to internalize as a CPaaS buyer:
- None of this changes the OTP itself. A verification code in a text message is still a verification code. What eIDAS affects is the identity-proofing layer above delivery — how strongly the user's claim to a number, address, or attribute is attested.
- Transposition runs on member-state timelines. The regulation is in force, but each member state adopts the national implementations on its own clock. A vendor claiming "eIDAS 2.0 ready" on a feature page is telling you a roadmap, not a shipped gate.
Where identity-proofing meets SMS verification
The regulation's intersection point with messaging is the phone number's status as a verified attribute. An OTP over SMS is a mechanism to prove control of a number at send time; eIDAS thinks about which attributes an authority has verified, and the number sometimes lands in that set — depending on how a member state's scheme treats it. Two shipped verification surfaces on Devotel Orbit connect directly to that intersection:
Pre-send number checks — Lookup and SIM swap. Before an OTP ever issues, the Lookup surface answers three questions: is the number valid, is the subscriber reachable right now, and was the SIM recently replaced under an account that should not have changed hardware. A SIM-swap check that fires after the code sent is a log line, not a control — the check that matters runs pre-send, on the same surface a national registry might eventually ask about. The buyer on the receiving end still owns the workflow of deciding "reject this enroll" versus "verify anyway," but the signal — the risk marker — is produced and consumed on the number-lookup layer.
The issued-and-checked OTP loop — the Verify API. Verification is a two-phase loop: a code is delivered to the user's device, and the user presents it back where your application compares it — with an expiry, an attempt ceiling, and a fraud-visibility layer that reports anomalies per-channel and per-destination (the OTP fraud-monitoring explainer covers what the monitor layer adds on top). Neither side of that loop is tied to eIDAS. A regulated identity scheme may eventually add a weaker or stronger requirement on what attribute was verified at enrollment, but the Verify loop itself — issue on request, check on present, report the outcome — stays the same control shape regardless of which regulation names it.
Where eIDAS should NOT be conflated with KYC
This is the trap buyers walk into when they first read "eIDAS" and "verification" together.
KYC (know-your-customer) is a document-collection problem, not an identity-proofing problem. On a CPaaS, KYC means the proofs a regulator or carrier asks for before they let a number activate or a sender identity carry traffic: business registration, use-case description, brand or agent authorization, tax or regulator IDs. The KYC documents walkthrough is the canonical orientation reading for that layer — it answers "which document classes does my onboarding list need," not "how strongly did I bind this user's phone number at verify time."
eIDAS-identity-proofing is a strength-of-binding problem. It asks whether a claim (the user says this number is theirs) was attested to a bar a scheme accepts. KYC's question is binary-threshold — did you upload the document or not? eIDAS's question is graduated — is the barcode, OTP, or wallet assertion strong enough to count?
The distinction matters because the two flows carry different control ownership. KYC documents are owned by your compliance function and travel via tenant-document libraries and sender registration profiles. Identity-proofing strength is owned by your verification workflow and travels via the Verify configuration (what channel counts, what check qualifies, how the SIM-swap gate pre-empts a swap pattern). Confusing the two causes two failure modes: treating a document upload as if it were a verification loop, and treating a verification loop as if document upload were part of it. On a platform that ships both surfaces, the two stay deliberately in their own lanes.
The tenant-owned control statement
The control ownership on eIDAS-adjacent topics is deliberately split in the same way the rest of Devotel Orbit's compliance surface is split: obligations live with your operation, controls live with the platform.
Concretely:
- Which OTP channel flows through Verify — SMS, voice, or a channel your flow-builder binds — is a tenant setting. Whether a recipient's number is enrolled through Lookup + SIM-swap checks or raw is also a tenant setting. eIDAS asks which configuration you run; it does not dictate which one you should run.
- The disclosure you owe — which attribute, which relay, which jurisdiction — is a counsel question. The platform's job is to make the verification telemetry you need auditable, per the fraud-monitoring explainer pattern.
- No regulated gate. A vendor that sells "eIDAS certified Send SMS" is selling a compliance label against a regulation whose national implementations are still on multiple timelines. The safe buyer posture: treat it as a tenant-owned configuration choice, not a checkbox to buy.
Frequently asked questions
Does Devotel Orbit support eIDAS 2.0 verification out of the box?
The honest answer is the same as it was for STIR/SHAKEN and ITU-T PIN: the regulation defines a trust-services framework, not a product gate. Orbit ships the verification layer (Lookup, SIM-swap, Verify, fraud monitoring) that intersects with a regulated identity scheme when one runs, and ships it without a vendor-applied attribution. Whether your flow needs to plug into a national wallet or a qualified-attribute relay is a couple of lines of architecture — not a button on the dashboard to wait for.
Is eIDAS the same thing as GDPR for identity?
No. GDPR governs how personal data is processed and protected; eIDAS governs how identities and attributes are attested and used. The overlap is that a verification flow produces personal data — and both rules apply — but they answer different questions. GDPR asks "is the processing lawful and minimal." eIDAS asks "is the attribute claim attested to a regulated bar." Treat the pair orthogonally in your compliance checklist, not as substitutes.
My compliance team asks for an 'eIDAS-ready verification' line item. What is the cleanest answer?
Point them to the control statement in this post: (a) the verification-control layer is shipped and tenant-owned, not gated on any eIDAS decision, (b) whatever attribute-attestation grade a member state's national scheme decides on can be hosted by the same Verify loop once both ends agree on semantics, and (c) no purchased checkbox — vendor or national — changes that the OTP itself is a flow you configure, not a regulation you inherit.
When should I re-read this list as timelines run?
Each member state adopts at its own pace. Watch for two signals in affected markets: a national digital-identity wallet GA announcement in your target countries, and regulator guidance naming which communication channel counts as a valid identity relay (SMS, RCS, voice, wallet push). Both signals feed into your Verify configuration, not a platform-version update.
The takeaway
eIDAS 2.0 widens the trust-services map, but the OTP you ship over SMS is still an OTP. The buyer's position in a transposition window is the same as in any standards window — run the verification control layer you own (lookup the number before you verify the channel against it, run the issue-and-check loop with the fraud telemetry attached, and keep the evidence of which channel was verified). The platform does not become eIDAS-compliant for you — it gives you the tenant-owned controls under whichever national scheme lands a defined bar. For the lookup and SIM-swap pre-send gate, the phone-number lookup guide is the reference; for the verification loop's fraud telemetry, the OTP fraud-monitoring explainer; and for the document-collection lane the new regulation deliberately does not touch, the KYC documents walkthrough.
Published 23 September 2026.