Expert articles on compliance, identity, PKI and operations. Hands-on, with no marketing spin.https://datargo.com/en/blog/2026-06-23T00:00:00+00:00Datargohttps://datargo.com/en/blog/api-security-supply-chain/2026-06-23T00:00:00+00:002026-06-23T00:00:00+00:00

NIS2 pulls the supply chain into the risk picture, and APIs are its quiet connectors. Why authorization flaws are the biggest API weakness, and why you can only secure what is cleanly documented.

<p>Software is rarely a monolith today. Modules, partner services and tenants talk to each other through interfaces, and these APIs are the quiet connectors of the supply chain. NIS2 explicitly requires supply chain security as part of the risk picture. That moves a question long treated as purely technical to the foreground: how secure, and how auditable, are your own interfaces?</p> <h2 id="the-interface-is-the-attack-surface">The interface is the attack surface</h2> <p>The most common API weaknesses are not exotic exploits but authorization flaws. In the OWASP API Security Top 10, Broken Object Level Authorization sits in first place: an API hands out data without properly checking whether the requesting account is allowed to see it at all. A changed object ID in the request is then enough to retrieve someone else&rsquo;s records. Three control points decide robustness in practice:</p> <ul> <li><strong>Per-object authorization:</strong> Every request checks whether the caller may see or change this specific object, not merely whether they are logged in.</li> <li><strong>Authentication:</strong> Tokens are short-lived, bound and revocable, rather than long-lived general-purpose keys.</li> <li><strong>Throttling:</strong> Rate limiting and quotas keep an interface from becoming a data-exfiltration point or a load vector.</li> </ul> <h2 id="what-you-do-not-document-you-cannot-secure">What you do not document, you cannot secure</h2> <p>Many incidents trace back not to known interfaces but to forgotten ones: shadow APIs that never reached the inventory, and zombie APIs left open after a version change. Without a complete, current inventory, any defence stays patchy. A well-maintained OpenAPI description is more than developer convenience here: it is the contract against which permissions, versions and expected behaviour can be checked at all. A dedicated developer portal that holds these descriptions in a versioned, multi-tenant way turns scattered knowledge into a traceable register.</p> <h2 id="security-as-a-demonstrable-property">Security as a demonstrable property</h2> <p>When the regulator asks, it is not enough to say the APIs are secured. What is required is evidence: which interfaces exist, in which version, with which permissions, and who retrieved what and when. Versioning, access logs and a maintained interface register turn security from an assertion into a property you can prove. This is the same logic NIS2 applies elsewhere to monitoring and reporting, only applied to the connectors between systems.</p> <p>A supply chain is only as trustworthy as its interfaces. And an interface that no one fully knows can be neither secured nor proven.</p>https://datargo.com/en/blog/passkeys-enterprise/2026-06-23T00:00:00+00:002026-06-23T00:00:00+00:00

A password plus an SMS or TOTP code remains phishable. Why FIDO2 passkeys solve the origin problem, what a risk-based rollout looks like, and which questions around recovery and device loss stay open.

<p>Phishing remains the most reliable way into corporate networks, and most second factors do little to change that. A password plus an SMS code, TOTP app or push approval counts as multi-factor authentication, yet at its core it is attackable: lure the user onto a fake page and the second factor can be captured in real time too. FIDO2 passkeys address exactly this point.</p> <h2 id="why-classic-mfa-stays-phishable">Why classic MFA stays phishable</h2> <p>The problem is not the number of factors but their transferability. A one-time code is a shared secret: it works wherever it is entered, including on the phishing page. What is missing is a binding to the genuine counterparty. That binding is precisely what WebAuthn, the standard behind passkeys, provides.</p> <h2 id="what-passkeys-do-differently">What passkeys do differently</h2> <p>A passkey is a cryptographic key pair. The private key never leaves the device, and signing only happens against the domain for which the passkey was registered. This origin binding renders the classic phishing redirect useless: a fake domain simply receives no valid signature. There is no secret that could be entered on the wrong site. Germany&rsquo;s BSI has published a formal threat model for this, and Technical Guideline BSI TR-03188 sets out requirements for operating a passkey server.</p> <h2 id="synced-device-bound-or-hardware-key">Synced, device-bound or hardware key</h2> <p>Not every passkey is the same. A sound rollout grades the variant by protection need:</p> <ul> <li><strong>Hardware security keys:</strong> for privileged access and administration, where the highest assurance matters.</li> <li><strong>Device-bound passkeys:</strong> on managed corporate devices, tied to the hardware and not syncable.</li> <li><strong>Synced passkeys:</strong> for the broader workforce, convenient across several devices, with a slightly lower hardening level.</li> </ul> <p>This grading matches the expectation that regulators and auditors increasingly voice: for sensitive administrative access, phishing-resistant authentication is treated more and more as a requirement, not a recommendation.</p> <h2 id="the-open-questions">The open questions</h2> <p>The hard part is not the sign-in but the edge cases. What happens when a device is lost? What does a recovery path look like that does not itself become a phishable back door? And how do you handle legacy systems that do not yet speak WebAuthn? A well-considered rollout answers these questions in advance instead of improvising them during an incident. As the connective layer of the platform, Datargo ID anchors single sign-on and MFA in one place, which bundles these questions rather than scattering them across each application.</p> <p>The decisive shift is this: away from a secret you can know and therefore give away, toward a key that stays bound to device and counterparty.</p>https://datargo.com/en/blog/data-act-cloud-switching/2026-06-23T00:00:00+00:002026-06-23T00:00:00+00:00

Since September 2025 the Data Act's switching rules apply to new cloud contracts, and in January 2027 the fee ban takes effect. Why changing providers turns from a negotiation point into a legal right, and what that means for architecture.

<p>Vendor lock-in was long a commercial lever: anyone wanting to leave paid for the exit, fought proprietary formats and lost weeks to migration work. The EU Data Act (Regulation (EU) 2023/2854) reverses that logic. The regulation has applied since 12 September 2025, and its Chapter VI turns switching cloud providers into an enforceable customer right.</p> <h2 id="what-has-applied-since-september-2025">What has applied since September 2025</h2> <p>Providers of data processing services (IaaS, PaaS, SaaS) must remove every obstacle that makes switching harder: pre-commercial, commercial, technical, contractual and organisational barriers alike. In practice this means a maximum notice period of two months, a 30-day transition window for the actual move (extendable to up to seven months where technically unfeasible) and the right to take data and digital assets along. For new contracts these duties already apply.</p> <h2 id="the-fee-brake-until-january-2027">The fee brake until January 2027</h2> <p>The Data Act phases out switching charges. On 12 January 2027 the full ban takes hold: no charges may then be levied for switching between data processing services. By 12 September 2027, legacy B2B contracts must also be cleared of unfair terms. Anyone who built pricing and contract models on exit costs will lose that foundation on a foreseeable schedule.</p> <h2 id="switching-is-more-than-a-data-export">Switching is more than a data export</h2> <p>The practical sticking point is functional equivalence. Exporting raw data is not enough if the target environment cannot do anything with it. The Data Act calls for open interfaces and, where possible, common formats so that a service can run again at its destination. Three questions decide in practice whether a switch is genuinely workable:</p> <ul> <li><strong>Data model:</strong> Are contents held in documented, open structures, or in a proprietary schema?</li> <li><strong>Interfaces:</strong> Are there stable, versioned APIs to export both live and historical data?</li> <li><strong>Metadata:</strong> Do configuration, permissions and processing logic travel along, or stay behind in the old system?</li> </ul> <h2 id="what-this-means-for-architecture">What this means for architecture</h2> <p>Sovereignty here is not a checkbox but a property of the system design. Whoever considers portability only at the moment of departure has already lost it. Open data models, documented export paths and hosting within the European legal area not only reduce lock-in risk, they are increasingly the precondition for meeting the Data Act duties at all. In a suite that holds its modules together through open interfaces and hosting in Frankfurt, changing providers is not a threat scenario but a traceable procedure.</p> <p>The Data Act does not ask whether you want to keep your customers. It asks whether they could leave if they wanted to.</p>https://datargo.com/en/blog/ai-transparency-customer-service/2026-06-23T00:00:00+00:002026-06-23T00:00:00+00:00

From 2 August 2026 the transparency obligations under Article 50 of the EU AI Act become enforceable. What the disclosure duty for chatbots and the labelling of AI-generated content mean in practice for customer service.

<p>Automated first responses, AI-assisted ticket triage, generated reply suggestions: in customer service, AI is already routine. From 2 August 2026 Article 50 of the EU AI Act becomes enforceable, bringing binding transparency obligations for exactly these systems. These duties are distinct from the rules for providers of general-purpose AI models (GPAI): the point here is not the model, but the interaction with people.</p> <h2 id="what-article-50-requires">What Article 50 requires</h2> <p>At its core sits a disclosure duty. Providers of AI systems intended for direct interaction with people (such as chatbots) must ensure that the person concerned is aware they are communicating with an AI system. The notice must be given at the latest at the time of the first interaction, unless the use of AI is obvious from the circumstances. On top of that, AI-generated or manipulated content must be marked as such in a machine-readable way, and content of public interest that could appear authentic has to be labelled separately.</p> <h2 id="what-informed-means-in-practice">What &ldquo;informed&rdquo; means in practice</h2> <p>A line in the legal notice is not enough. The disclosure has to be clear, given before or at the start of the conversation, and understandable to the user. In practice that means more than a banner:</p> <ul> <li><strong>Visibility:</strong> The AI notice sits at the start of the dialogue, not in a collapsible footnote.</li> <li><strong>Language:</strong> The notice appears in the language the person uses to make contact, not only in English.</li> <li><strong>Handover:</strong> When the conversation moves between AI and a human agent, it should stay clear who is currently speaking.</li> </ul> <h2 id="more-than-a-notice-banner">More than a notice banner</h2> <p>The harder side is demonstrability. Anyone who wants to show, when the regulator asks, that the notice was actually and consistently displayed needs a record of the configuration and of the notices served. In multi-tenant environments there is an added layer: each tenant runs its own channels, languages and escalation paths, so the transparency logic has to work per tenant, not just globally. A customer service hub like Datargo CRM, which brings live chat, tickets and contacts together in a multi-tenant way, offers the natural place to anchor disclosure, language mapping and human handover consistently.</p> <p>Article 50 does not ban AI in customer service. It only requires that no one is left in the dark about who, or what, they are talking to.</p>https://datargo.com/en/blog/47-day-tls-certificates/2026-06-09T00:00:00+00:002026-06-09T00:00:00+00:00

The CA/Browser Forum is cutting maximum TLS lifetimes to 47 days in stages. What the 200-, 100- and 47-day steps mean for discovery, renewal automation and operations teams.

<p>The debate is settled, and part of the outcome is already operational reality: since 15 March 2026, publicly trusted TLS certificates may be valid for at most <strong>200 days</strong>, down from 398. That is the first step in a roadmap the CA/Browser Forum adopted in April 2025 with Ballot <strong>SC-081v3</strong>: unanimously, with 29 votes in favour and none against. At the end of that roadmap sits a maximum lifetime of <strong>47 days</strong>.</p> <p>If you still order certificates by hand and track them in a calendar, treat the next three years as a rebuild project, not a series of individual appointments.</p> <h2 id="the-roadmap-in-numbers">The roadmap in numbers</h2> <p>Maximum validity drops in clearly dated steps:</p> <ul> <li><strong>until 14 March 2026:</strong> 398 days (the previous standard)</li> <li><strong>from 15 March 2026:</strong> 200 days (in effect today)</li> <li><strong>from 15 March 2027:</strong> 100 days</li> <li><strong>from 15 March 2029:</strong> 47 days</li> </ul> <p>In parallel, and this is the operationally harder part, the reuse window for Domain Control Validation (DCV) shrinks. Once you have proven control over a domain, that proof may be &ldquo;reused&rdquo; for a much shorter period before it must be re-established:</p> <ul> <li><strong>from 15 March 2026:</strong> 200 days</li> <li><strong>from 15 March 2027:</strong> 100 days</li> <li><strong>from 15 March 2029:</strong> 10 days</li> </ul> <p>For OV and EV certificates, the reuse period for vetted organisation data (Subject Identity Information) additionally falls from 825 to 398 days on 15 March 2026.</p> <p>So the 47 days are only the headline. The 10-day DCV reuse from 2029 is the real metronome: from then on, you effectively have to re-prove control of your domain every ten days.</p> <h2 id="why-the-reduction-is-happening">Why the reduction is happening</h2> <p>The reasoning is straightforward. A certificate is a trust statement with an expiry date. The longer it is valid, the longer a mis-issuance, a compromised key or an outdated cryptographic parameter keeps having effect. The classic countermeasure, revocation via CRL and OCSP, works unreliably in practice: revocation lists are not evaluated promptly everywhere, and OCSP is increasingly being deprecated. Short lifetimes replace revocation with expiry. A problem heals itself because the affected certificate will soon be invalid anyway.</p> <p>The second driver is crypto-agility. If you renew certificates regularly, you can change algorithms, key lengths and profiles in ongoing operation, a precondition for the upcoming migration to post-quantum methods. Long lifetimes, by contrast, cement the status quo.</p> <h2 id="what-this-means-for-operations">What this means for operations</h2> <p>The central consequence is mundane and unavoidable: <strong>manual renewal no longer scales.</strong> A 47-day certificate, with a sensible buffer, gets replaced roughly every 30 days. Across a mid-sized estate, that is no longer a calendar entry but a process that has to run without human intervention.</p> <p>Three capabilities decide whether this rebuild succeeds:</p> <p><strong>Automation.</strong> ACME (RFC 8555) is the established standard for automatic issuance and renewal, not only for Let&rsquo;s Encrypt, but increasingly for commercial and internal CAs too. Where ACME does not reach, you need API-driven renewal workflows with approval, so that compliance controls remain intact.</p> <p><strong>Discovery.</strong> You can only automate what you know about. The typical outage in 2029 will not be the well-maintained certificate on the main system, but the forgotten one on a load-balancer endpoint, an appliance or in a cloud account nobody is watching any more. Active network scans and passive cloud discovery are what keep short lifetimes from turning into short-notice outages.</p> <p><strong>Ownership.</strong> Every certificate needs a clearly assigned owner, a known CA and a defined renewal procedure. An inventory that carries those three facts per certificate is the real insurance against the 47-day reality.</p> <p>This pattern (discovery first, then CA-agnostic automation with approval) is exactly what underpins our NextPKI module. The regulatory direction is independent of any tool: whoever makes the estate visible and automates renewal is prepared, regardless of which instrument they use.</p> <h2 id="what-makes-sense-now">What makes sense now</h2> <p>Three years sounds like plenty of time, but the 200-day step is already running. Concretely, it is worth doing now: a complete inventory of all TLS certificates across network, cloud and endpoints; identifying every place that still renews by hand today; a pilot of ACME-based auto-renewal on non-critical services; and clarifying which internal systems can technically sustain ten-day domain re-validation at all by 2029.</p> <p>The 47 days are not arriving by surprise, and not all at once. They arrive in steps, and the first one is already here.</p>https://datargo.com/en/blog/eidas-2-eudi-wallet/2026-06-09T00:00:00+00:002026-06-09T00:00:00+00:00

EU member states must provide the EUDI Wallet by December 2026. A sober overview of the technical and legal groundwork companies should lay now as relying parties.

<p>In about six months a deadline expires that many companies still treat as distant regulation: by <strong>24 December 2026</strong>, all 27 EU member states must provide their citizens and residents with at least one <strong>European Digital Identity Wallet (EUDI Wallet)</strong>. The legal basis is Regulation (EU) 2024/1183 (&ldquo;eIDAS 2.0&rdquo;), in force since 20 May 2024.</p> <p>For most companies the more pressing question is not when the wallet arrives, but when they will have to <strong>accept</strong> it. And that deadline follows immediately.</p> <h2 id="where-the-rollout-stands-in-june-2026">Where the rollout stands in June 2026</h2> <p>The regulatory foundation is well advanced. The Architecture and Reference Framework (ARF) is at version 2.8, and 31 implementing acts have already been published, referring to dozens of technical standards. On 8 April 2026 the European Commission added the implementing regulation on wallet enrollment, a central building block, because it governs how users get their identity securely into the wallet.</p> <p>Member-state progress, however, is uneven. France is considered furthest along with &ldquo;France Identité&rdquo;, already running a production service and expanding it into the official EUDI Wallet; Italy and Poland follow closely. <strong>Germany</strong> has announced that it will launch its state-driven version on <strong>2 January 2027</strong>, that is, shortly after the EU deadline.</p> <h2 id="relying-party-the-role-that-affects-almost-everyone">Relying party: the role that affects almost everyone</h2> <p>A relying party is any entity that wants to rely on wallet attestations for identification or authentication, from onboarding through age verification to strong customer authentication.</p> <p>The timing logic of the regulation is clear: once the wallets are available, regulated sectors and very large online platforms must accept the EUDI Wallet for authentication <strong>roughly one year later</strong>. The provisioning deadline at the end of 2026 thus becomes an acceptance obligation from around the end of 2027 for many. Banks, insurers, telecommunications and energy providers, healthcare and large platforms are in the front row; everyone else may accept the wallet voluntarily and is well advised not to start the integration at the last minute.</p> <h2 id="what-a-relying-party-should-clarify-now">What a relying party should clarify now</h2> <p><strong>Registration.</strong> Relying parties must register with a national registrar before first use, declaring which attributes they request and for what purpose. This registration is not a formality but the legal basis for being allowed to request data at all.</p> <p><strong>Data minimisation.</strong> The wallet is built for selective disclosure: users should share exactly the attributes a service genuinely needs, for instance &ldquo;over 18&rdquo; rather than a full date of birth. Requesting more than the purpose justifies clashes with both the eIDAS logic and the GDPR. Defining the minimal attribute set per use case is therefore the first substantive task, not the last.</p> <p><strong>Technical integration.</strong> Presenting attestations relies on established open protocols and formats, including OpenID for Verifiable Presentations and the attestation formats ISO/IEC 18013-5 (mdoc) and SD-JWT VC. Added to these are trust lists, through which a service verifies that a presented wallet and its issuers are genuine and authorised. Betting on standards rather than proprietary adapters keeps the wallets of different member states within reach.</p> <p><strong>Use cases and governance.</strong> Onboarding and KYC, age verification, strong customer authentication and qualified electronic signatures via the wallet are the obvious fields. Each of these cases needs clean consent and logging logic: who requested and received which attribute, when, and for what purpose.</p> <p>In our Datargo ID module, this relying-party role is exactly the through-line: a single sign-on as the bracket, prepared for the EUDI path. The point itself, though, is independent of any tool: every accepting party sets the course for registration, attribute minimisation and standards-based integration for itself.</p> <h2 id="the-sober-timeline">The sober timeline</h2> <p>Wallets are provisioned by the end of 2026, national solutions appear from early 2027 (Germany on 2 January 2027), and roughly a year after availability the acceptance obligation takes effect for regulated sectors. That sounds like 2027 and 2028, but it begins as a preparation task today: determine the attribute requirement, clarify the registration path, pilot a standards-based integration. The deadline is set; what remains voluntary is only the timing of preparation, not whether to prepare.</p>https://datargo.com/en/blog/cyber-resilience-act-reporting-2026/2026-06-09T00:00:00+00:002026-06-09T00:00:00+00:00

The first binding CRA obligations apply from 11 September 2026. What reporting actively exploited vulnerabilities, SBOMs and security by design mean in practice for manufacturers, importers and distributors.

<p>In about three months a regulation turns into operational reality. From <strong>11 September 2026</strong> the first binding obligations of the Cyber Resilience Act (Regulation (EU) 2024/2847) take effect, and they happen to be the ones that demand the most process: reporting actively exploited vulnerabilities and severe security incidents. The remaining product and conformity obligations follow with full application on <strong>11 December 2027</strong>.</p> <p>Anyone who manufactures, imports or distributes products with digital elements in the EU should therefore treat September not as a distant date, but as the day a working reporting path has to exist.</p> <h2 id="what-begins-on-11-september-2026">What begins on 11 September 2026</h2> <p>The CRA requires manufacturers to report an actively exploited vulnerability or a severe security incident through a staged procedure. An early warning goes to the responsible CSIRT and to ENISA within 24 hours, a fuller notification follows within 72 hours, and a final report comes later. This runs through a single European reporting platform.</p> <p>The distinction from NIS2 matters: there, an affected entity reports incidents in its own operations. Under the CRA, the manufacturer reports a vulnerability in its product, regardless of which customer is affected by its exploitation. Both regimes can apply at once, and they call for different reporting paths.</p> <h2 id="what-is-added-by-december-2027">What is added by December 2027</h2> <p>The reporting duty is only the first building block. With full application, the CRA demands demonstrable security across the entire product lifecycle:</p> <ul> <li><strong>Security by design:</strong> security is part of development, not a later add-on. This includes secure default settings and an attack surface kept as small as possible.</li> <li><strong>Software Bill of Materials (SBOM):</strong> manufacturers must know and document the components and dependencies they ship. Without this inventory, a new vulnerability leaves the simple question unanswered: is my product affected?</li> <li><strong>Vulnerability management and updates:</strong> security updates must be provided for at least five years, or for the expected lifetime of the product if that is shorter.</li> <li><strong>CE marking:</strong> from December 2027, products with digital elements may no longer be placed on the EU market without CRA conformity.</li> </ul> <p>There is no exemption for small and medium-sized enterprises. Anyone making or importing covered products falls under the regulation regardless of size.</p> <h2 id="what-this-means-in-practice">What this means in practice</h2> <p>The reporting duty from September is organisationally harder than the short deadline suggests. Twenty-four hours to an early warning is no time to start clarifying who is responsible. It requires a named owner in advance, a documented process, and the technical ability to detect an incident promptly at all.</p> <p>This is where two topics that are often handled separately come together: detecting (monitoring and security posture) and evidencing (a traceable record of who reported what and when). Anyone who has already built both for NIS2 or ISO 27001 can build on it. In our Datargo Monitor module this pattern of continuous monitoring and auditable evidence is built in, but the regulatory requirement stands independently of any tool: without reliable detection, every reporting deadline runs empty.</p> <h2 id="what-is-worth-doing-now">What is worth doing now</h2> <p>Three steps pay off before September. First, clarify which of your own products count as &ldquo;products with digital elements&rdquo; and thus fall within scope. Second, set up the reporting process for actively exploited vulnerabilities, with clear ownership and the 24-hour, 72-hour and final-report deadlines. Third, begin building an SBOM, because it is the precondition for being able to say at all, in an emergency, whether you are affected.</p> <p>The 11th of September 2026 marks not the end of preparation, but the start of the obligation. The work behind it, detection and documentation, cannot be caught up in 24 hours.</p>https://datargo.com/en/blog/data-sovereignty-data-privacy-framework/2026-06-02T00:00:00+00:002026-06-02T00:00:00+00:00

The EU-US Data Privacy Framework remains valid for now, but is under review. Why hosting location, operator control and key sovereignty are not compliance checkboxes but architecture decisions with a long half-life.

<p>Anyone transferring personal data to the United States has relied since 2023 on the adequacy decision for the EU-US Data Privacy Framework (DPF). In September 2025 the General Court of the European Union (EuG) dismissed a challenge against it, leaving the framework a valid legal basis. But the matter is not closed: in late October 2025 an appeal was lodged with the Court of Justice (Case C-703/25 P). Another reversal, a &ldquo;Schrems III&rdquo;, is not ruled out.</p> <p>This uncertainty is no cause for panic, but a good occasion to lift a question from the compliance level to the architecture level.</p> <h2 id="why-this-is-more-than-a-checkbox">Why this is more than a checkbox</h2> <p>The comfortable way to handle data transfers is to treat them as a contractual matter: as long as a valid decision or standard contractual clauses are in place, the transfer is covered. That is legally true, but it misjudges the actual risk. Every legal basis for third-country transfers has been provisional for years. Safe Harbor fell in 2015, the Privacy Shield in 2020, and the current framework is under judicial review. Anyone aligning their architecture to a legal basis that wobbles every few years builds in a dependency they do not control.</p> <p>The more robust question is not &ldquo;is the transfer covered&rdquo; but &ldquo;does the transfer happen at all&rdquo;. Data that does not leave the EU and is not subject to third-country access needs no adequacy decision.</p> <h2 id="three-architecture-decisions">Three architecture decisions</h2> <p><strong>Hosting location.</strong> Where the data physically resides is the first and most visible decision. A data centre in Frankfurt rather than a US region is the foundation, but not sufficient on its own, because location alone says nothing about control.</p> <p><strong>Operator control.</strong> What matters is who has legal and actual access to the data and the infrastructure. A server located in the EU but operated by a company subject to a third-country law with far-reaching disclosure duties only solves the problem halfway. The question of the operator&rsquo;s applicable law therefore belongs to the architecture, not just the contract.</p> <p><strong>Key sovereignty.</strong> Whoever holds the keys controls access. Encryption in which only the customer holds the keys makes third-party access technically ineffective, even if it were legally compelled. Key sovereignty shifts control from a promise to a technical property.</p> <h2 id="sovereignty-as-a-default-not-a-retrofit">Sovereignty as a default, not a retrofit</h2> <p>These three decisions are hard and expensive to change after the fact. They belong at the start of an architecture, not in a project that only kicks off once a court overturns the next decision. This is exactly what sovereignty by design means: not the after-the-fact securing of a transfer, but a design that makes the problematic transfer unnecessary in the first place.</p> <p>In our platform, EU hosting in Frankfurt is the default, not the premium option. The point itself, though, is independent of any provider: whoever settles location, operator control and key sovereignty early makes themselves independent of the next judicial turn.</p> <p>The Data Privacy Framework may survive the current review or it may not. An architecture that does not depend on the answer is the calmer choice either way.</p>https://datargo.com/en/blog/ai-act-gpai-enforcement-2026/2026-05-26T00:00:00+00:002026-05-26T00:00:00+00:00

Active enforcement of the GPAI obligations begins in August. A sober overview of what applies now, what the May 2026 Digital Omnibus postponed, and which deadlines remain.

<p>The EU AI Act has been in force since August 2024, but many of its obligations take effect in stages. One date stands out: on <strong>2 August 2026</strong> active enforcement against providers of general-purpose AI models (GPAI) begins through the EU AI Office, and national sanction regimes take effect in parallel. In Germany the accompanying AI Measures and Innovation Act (KI-MIG) applies. Anyone who uses or provides AI should know the deadline, but also the most recent postponements.</p> <h2 id="what-begins-on-2-august-2026">What begins on 2 August 2026</h2> <p>The obligations for GPAI models have applied since August 2025. What is added in August 2026 is enforcement: one year after applicability, the AI Office gains the powers to actually act on them. These include information requests, access to models and, as a last resort, the recall of a model. An obligation on paper thereby becomes an enforceable one.</p> <p>For most companies the relevant role is not that of the GPAI provider, but that of a deployer or provider of downstream systems. They too should know which transparency and documentation obligations take effect when.</p> <h2 id="what-the-may-2026-digital-omnibus-postponed">What the May 2026 Digital Omnibus postponed</h2> <p>On 7 May 2026 the EU, through the so-called Digital Omnibus, stretched the timeline for individual sub-obligations. This does not change the August deadline for GPAI enforcement, but it shifts other building blocks:</p> <ul> <li><strong>High-risk systems under Annex III:</strong> postponed to 2 December 2027.</li> <li><strong>High-risk systems under Annex I:</strong> postponed to 2 August 2028.</li> <li><strong>Transparency obligations under Article 50</strong> (such as labelling AI-generated content): postponed to 2 December 2026.</li> <li><strong>AI regulatory sandboxes:</strong> postponed to 2 August 2027.</li> </ul> <p>This stretching is not a free pass. It buys time for the more demanding high-risk requirements, but leaves GPAI enforcement and the national sanctions in August untouched.</p> <h2 id="what-this-means-in-practice">What this means in practice</h2> <p>Three tasks are worthwhile regardless of the exact date. First, an inventory: which AI systems does the company use or provide, and into which risk class do they fall? Without this clarity, no deadline can be planned meaningfully. Second, transparency: from December 2026, Article 50 requires that certain AI interactions and AI-generated content be made recognisable. Third, documentation, because enforcement from August rests on obligations not only being met but also being evidenced.</p> <p>This last point connects the AI Act with the other compliance regimes. Whether NIS2, DORA or the AI Act, the recurring requirement is a traceable, auditable record of what a system does and who is accountable for it. A platform that produces this record as a by-product of operation anyway makes preparation easier, for any regime. The task itself, however, stays the same: first know what you operate, then evidence that it complies.</p> <p>The 2nd of August 2026 is not an abstract date. It is the point at which the GPAI obligations grow teeth. What the Digital Omnibus postponed concerns the high-risk track, not this core.</p>https://datargo.com/en/blog/eudi-wallet-protocols-sdjwt-openid4vp/2026-05-12T00:00:00+00:002026-05-12T00:00:00+00:00

How a relying party actually validates a wallet attribute: a technical look at selective disclosure, presentation protocols and trust lists behind the EUDI Wallet.

<p>Most of the conversation around the EUDI Wallet sits at the political and organisational level: member-state provisioning by the end of 2026, registration duties, acceptance deadlines. But anyone who actually wants to accept the wallet eventually faces a technical question: how exactly do I verify that a presented attribute is genuine, valid and sufficient for my purpose? This article looks at the verification side and the building blocks that come together there.</p> <h2 id="three-formats-one-interplay">Three formats, one interplay</h2> <p>The Architecture and Reference Framework (ARF), now at version 2.x, sets the technical standards. Three of them are central for relying parties.</p> <p><strong>SD-JWT VC</strong> (Selective Disclosure JWT Verifiable Credential) is a credential format that enables selective disclosure. The issuer signs a bundle of attributes, but in a way that lets the user reveal individual ones without exposing the rest. Technically this works through salted hashes: each attribute is hashed individually, and the signature covers the hashes. Whoever discloses an attribute supplies the matching plaintext and salt, the rest stays hidden, and the signature remains verifiable.</p> <p><strong>ISO/IEC 18013-5 (mdoc)</strong> is the format originating from the mobile driving licence, used in parallel for certain attestations in the EUDI context. A relying party should be able to process both formats, since member states do not all proceed identically.</p> <p><strong>OpenID for Verifiable Presentations (OpenID4VP)</strong> is the protocol that carries the presentation. It defines how a relying party makes a request (which attributes, for what purpose) and how the wallet returns the signed response.</p> <h2 id="what-selective-disclosure-changes-in-practice">What selective disclosure changes in practice</h2> <p>The common example is age verification. Instead of transmitting the full date of birth, the wallet can disclose the derived attribute &ldquo;over 18&rdquo; alone. For the relying party this means formulating requests so that they receive exactly the predicate they need, not the full data set behind it. Data minimisation here is not an afterthought bolted on for privacy, but built into the protocol.</p> <h2 id="the-hard-part-trust-not-validity">The hard part: trust, not validity</h2> <p>Checking a signature is the easy task. The hard one is the question behind it: is the issuer who signed this attribute actually authorised and genuine? This is where <strong>trust lists</strong> come in. The EU and the member states maintain registries through which a relying party can reliably establish whether a wallet and its issuers are authentic and authorised. Without this connection you verify a correct signature, but you do not know whether the identity behind it is trustworthy.</p> <p>The reverse direction matters just as much: the relying party itself must register with a national registrar before first use, declaring which attributes it requests and for what purpose. Only this registration is the legal basis for being allowed to request data at all.</p> <h2 id="why-betting-on-standards-pays-off">Why betting on standards pays off</h2> <p>Choosing open formats and protocols over proprietary adapters keeps the wallets of different member states within reach, without integrating anew per country. In our Datargo ID module this relying-party role is the through-line, from single sign-on to the EUDI path. The technical core, though, holds independently of any tool: whoever can process SD-JWT VC, mdoc and OpenID4VP and connects the trust lists correctly is ready for verification, no matter which member state the wallet comes from.</p> <p>Provisioning the wallet is a political deadline. Setting verification up cleanly is a technical task, and it starts with understanding these three building blocks.</p>https://datargo.com/en/blog/e-invoice-archiving-gobd/2026-04-21T00:00:00+00:002026-04-21T00:00:00+00:00

From 2027 the structured e-invoice becomes the mandatory format. What audit-proof retention, the shortened eight-year period and the difference between a visual copy and the authoritative data set mean in practice.

<p>The debate around e-invoicing mostly turns on issuing and receiving. The quieter but longer-lived obligation only begins afterwards: retention. A structured invoice is not a document in the classic sense but a data set, and it must remain unalterable and machine-readable for years. Building that into your processes from the start avoids costly rework later.</p> <h2 id="what-changed-about-the-retention-period">What changed about the retention period</h2> <p>For a long time, accounting records had to be kept for ten years. Germany&rsquo;s Fourth Bureaucracy Relief Act (BEG IV) shortened this to <strong>eight years</strong> as of 1 January 2025. The new period applies to all records whose previous ten-year period had not yet expired at that point.</p> <p>Two qualifications matter. First, the reduction covers accounting records such as invoices, receipts and payment vouchers. Annual financial statements and the procedural documentation stay at ten years. Second, the shorter period is not purely a relief: being allowed to delete records after eight rather than ten years means the deletion concept should be adjusted accordingly, also with the GDPR in mind. A blanket extension &ldquo;to be safe&rdquo; sits in tension with the duty not to retain personal data longer than necessary.</p> <h2 id="what-audit-proof-demands-technically">What &ldquo;audit-proof&rdquo; demands technically</h2> <p>For electronic records subject to retention, the GoBD essentially require three properties: immutability, complete and timely capture, and continuous availability and machine evaluability across the whole period. Immutability does not mean a file sitting in a folder nobody touches. It means subsequent changes are technically excluded or fully logged, and that the original state remains recoverable.</p> <p>For structured formats a second, often underestimated, requirement is added.</p> <h2 id="a-visual-copy-is-not-the-data-set">A visual copy is not the data set</h2> <p>An XRechnung is a pure XML data set. ZUGFeRD is hybrid: a PDF with embedded XML. The decisive point: what must be retained is the <strong>structured data set</strong>, not a PDF visual copy generated from it. Anyone who prints or renders an incoming XRechnung as a PDF and archives only that image has not retained the authoritative record in a GoBD-compliant way. The original is the XML structure, and it is exactly this that must be available unchanged and evaluable for eight years.</p> <p>This has consequences for the architecture. Producing a nice view on receipt is not enough. The data set must be stored in its structured form, indexed and protected against alteration. A procedural documentation records exactly how this path runs: from receipt through checking to storage.</p> <h2 id="where-this-comes-together-in-practice">Where this comes together in practice</h2> <p>From 2027 at the latest, when the structured e-invoice becomes the rule in domestic B2B traffic, three things meet: the format (XRechnung or ZUGFeRD per EN 16931), the booking in the commercial core, and audit-proof storage. In our Datargo ERP module, e-invoicing per EN 16931 and GoBD accounting are laid out as one continuous path, but the requirement itself is tool-independent: the authoritative data set must stay unchanged, evaluable and findable for the full period.</p> <p>The eight-year period sounds like less effort than the old one. In substance it merely shifts the effort: away from deletion, towards clean retention of the right object, namely the data set, not its image.</p>https://datargo.com/en/blog/nis2-practice-evidence/2026-04-14T00:00:00+00:002026-04-14T00:00:00+00:00

Since December 2025, NIS2 is German law. What monitoring, reporting and logging must actually prove when the regulator asks, and where companies stand now.

<p>Since 6 December 2025, NIS2 is law in Germany. The NIS2 Implementation and Cybersecurity Strengthening Act (NIS2UmsuCG) was passed by the Bundestag on 13 November 2025, confirmed by the Bundesrat on 20 November, and entered into force with no transition period. Around 29,500 companies across 18 sectors are in scope. The BSI registration deadline on 6 March 2026 has passed; late registration remains possible and is advisable.</p> <p>Many organisations treated the rollout as a registration and documentation task. The harder part begins afterwards: being able to prove, when it counts, what actually happened.</p> <h2 id="the-clock-runs-in-hours-not-weeks">The clock runs in hours, not weeks</h2> <p>The reporting duties (Section 32) are staggered and tightly timed. For a significant incident: an early warning within 24 hours, a notification within 72 hours, a final report within one month. These deadlines can only be met if an incident is detected quickly and reconstructed traceably. Whoever notices only while writing the report that the necessary data is missing has effectively already missed the deadline.</p> <h2 id="what-the-regulator-wants-to-see">What the regulator wants to see</h2> <p>Section 30 requires risk-management measures: monitoring, logging, incident handling, business continuity and supply-chain security. The decisive difference lies between &ldquo;we run monitoring&rdquo; and &ldquo;we can prove what happened, and when&rdquo;. A supervisory authority does not accept a statement of intent, it wants evidence.</p> <p>Evidence is defensible when it has three properties:</p> <ul> <li><strong>Gapless:</strong> detection, escalation and response are continuously timestamped, with no dark phases in the timeline.</li> <li><strong>Unalterable:</strong> logs and incident histories are append-only, not quietly correctable after the fact.</li> <li><strong>Reconstructable:</strong> from the trail, the incident chronology can be derived in a way that maps onto the 24-hour, 72-hour and one-month deadlines.</li> </ul> <p>This is exactly where many setups fail: monitoring exists, but the data is scattered, overwritable, or cannot be assembled into an audit-proof chronology.</p> <h2 id="responsibility-cannot-be-delegated-away">Responsibility cannot be delegated away</h2> <p>Section 38 puts management on the hook to approve the measures and oversee their implementation. That responsibility cannot be handed off to IT. Section 65 sets the frame with fines of up to 10 million euros. This shifts NIS2 from a technical task to a leadership one.</p> <h2 id="what-makes-sense-now">What makes sense now</h2> <p>Three steps pay off immediately: map your own obligations cleanly onto Sections 30 and 32; set up detection so that the 24-hour early warning is realistically achievable; and move logging onto unalterable, sufficiently long-retained trails. A single rehearsed reporting run quickly reveals where the chronology breaks.</p> <p>In our Datargo Monitor module, monitoring, security posture and an append-only audit trail are connected so that NIS2 evidence can be produced on demand. The point itself, though, is independent of any tool, namely to run detection and logging so that what remains at the end is an audit-proof chronology and not a pile of scattered log lines.</p> <p>NIS2 does not ask whether you run monitoring. It asks whether you can prove it.</p>https://datargo.com/en/blog/acme-internal-pki-mtls/2026-03-17T00:00:00+00:002026-03-17T00:00:00+00:00

Short lifetimes can only be managed through automation. Why internal PKI, service mesh and mTLS follow different patterns than the public web, and how ACME works behind the firewall too.

<p>Shortening public TLS lifetimes towards an eventual 47 days has created an awareness that manual renewal no longer scales. What often gets overlooked: inside a company there are usually far more certificates than at the outward-facing edge. Service-to-service communication, mTLS in a service mesh, internal APIs and database connections all live on certificates, and these follow different patterns than the public web.</p> <h2 id="why-internal-does-not-mean-simpler">Why &ldquo;internal&rdquo; does not mean &ldquo;simpler&rdquo;</h2> <p>At the public web server the situation is tidy: a handful of domains, a public CA, a clearly defined validation path. Internally the ratio inverts. Here there are often hundreds or thousands of short-lived endpoints that appear and vanish dynamically, for instance when an orchestrator starts new containers. An internal CA issues certificates for them that nobody sees publicly, but which expire just the same, must renew just the same, and take down a service just the same when they fail.</p> <p>The difference from the public world is therefore not lesser importance, but higher frequency and dynamism. With mTLS, where both sides authenticate each other with a certificate, the number of identities to manage doubles on top of that.</p> <h2 id="acme-is-not-just-for-lets-encrypt">ACME is not just for Let&rsquo;s Encrypt</h2> <p>ACME (RFC 8555) became known as the protocol for automatic issuance and renewal, above all through Let&rsquo;s Encrypt on the public web. The protocol itself, however, is CA-agnostic. An internal CA can offer an ACME interface, and then internal services renew themselves through the same mechanism, without anyone ordering a certificate by hand.</p> <p>For internal validation, different challenge types apply than on the public web. The HTTP challenge common for public domains rarely fits internal services. Instead, DNS-based methods or, depending on the environment, platform-bound identity proofs come into play. Service meshes partly solve this internally through their own identity layer and short-lived certificates with lifetimes of hours rather than weeks.</p> <h2 id="what-makes-the-difference">What makes the difference</h2> <p>Three capabilities decide whether internal automation holds.</p> <p><strong>Discovery facing inward too.</strong> The dangerous outage is rarely the well-tended front-end certificate. It is the forgotten one on an internal service, an appliance, or in a cluster nobody actively watches anymore. An inventory must capture internal endpoints as much as public ones.</p> <p><strong>A CA-agnostic view.</strong> In environments that have grown over time, several CAs usually coexist: a public one for the outer edge, one or more internal, and perhaps a cloud-native one. Management that offers a unified view and unified renewal across all of them prevents each CA from becoming its own island with its own gaps.</p> <p><strong>Renewal with control.</strong> Full automation is the goal, but not at the price of lost traceability. Where needed, automatic renewal includes a documented approval and logging step, so that even at high frequency it stays clear what was issued when.</p> <p>Exactly this pattern, discovery first, then CA-agnostic automation with approval, underlies our NextPKI module. The thrust, though, holds independently of any tool: whoever masters the short lifetimes of the outer edge but overlooks the interior has not got the actual volume under control.</p> <p>The 47-day discussion is a good occasion to widen the view. Most of a company&rsquo;s certificates are not in the shop window, but in the engine room.</p>https://datargo.com/en/blog/dora-third-party-risk/2025-12-09T00:00:00+00:002025-12-09T00:00:00+00:00

Since January 2025, DORA applies in the financial sector, with consequences for every supplier. What the register of information, reporting chains and the first critical designations mean.

<p>DORA, the Digital Operational Resilience Act (Regulation (EU) 2022/2554), has applied to the European financial sector since 17 January 2025. Since 19 November 2025, oversight has become concrete: the European Supervisory Authorities EBA, EIOPA and ESMA published the first official list of 19 ICT third-party providers designated as critical, among them AWS, Google Cloud, Microsoft, Oracle, SAP, IBM and Deutsche Telekom. The list is updated annually.</p> <p>The instinctive reaction of many IT providers is: this does not concern me, I am not a bank. That is a fallacy. DORA travels down the supply chain.</p> <h2 id="why-the-regulation-reaches-every-supplier">Why the regulation reaches every supplier</h2> <p>Financial entities carry the risk of their ICT outsourcing themselves and must manage it demonstrably. By 30 April 2025 they had to report their register of information, a complete record of all contractual arrangements with ICT third-party providers. With that, every outsourcing is visible to the regulator, including those to non-critical providers.</p> <p>Whatever obligations the financial entity carries, it passes on contractually to its providers. In practice, financial customers now demand:</p> <ul> <li><strong>DORA-compliant contract clauses</strong> with clear performance, security and termination terms.</li> <li><strong>Audit and access rights</strong>, so that the customer and the regulator can inspect.</li> <li><strong>Transparency over sub-outsourcing</strong>, that is, who else sits behind the provider.</li> <li><strong>Reporting chains for incidents</strong>, fast enough for the financial customer to meet its own deadlines.</li> <li><strong>Exit and continuity plans</strong>, along with evidence from resilience testing.</li> </ul> <h2 id="incident-reporting-is-a-chain-not-a-form">Incident reporting is a chain, not a form</h2> <p>For major ICT incidents, DORA requires staggered reporting: an initial notification within a few hours of classification, an intermediate report and a final report within one month. For suppliers this means: the incident must not only be detected internally, the financial customer must be informed in time to keep its own regulatory clock. Whoever reports too late or too vaguely endangers the customer&rsquo;s compliance, and with it the business relationship.</p> <h2 id="designated-critical-means-direct-oversight">Designated critical means direct oversight</h2> <p>Whoever is named a critical ICT third-party provider falls under the direct oversight of a lead overseer at EU level. Because the list is updated annually, the designation is not a static state: whoever is not listed today may be listed as their importance to the financial sector grows.</p> <h2 id="what-makes-sense-now">What makes sense now</h2> <p>For ICT providers with financial customers, it pays to review your own contracts for DORA clauses, document sub-outsourcing cleanly, and rehearse incident reporting so that the chain up to the financial customer holds within hours. In our Datargo Monitor module, monitoring, an incident engine and an append-only audit trail interlock so that the evidence for such reporting chains can be produced. The point itself, though, is independent of any tool, namely to document your own resilience so that the financial customer can rely on it.</p> <p>DORA is not a banking topic alone. It is the requirement your financial customers now pass on to you.</p>https://datargo.com/en/blog/post-quantum-migration/2025-09-16T00:00:00+00:002025-09-16T00:00:00+00:00

With the final NIST standards and 'harvest now, decrypt later', crypto-agility becomes an operational task. A practical start on inventory and phased migration.

<p>Since August 2024, the first three post-quantum standards have been final. NIST published FIPS 203 (ML-KEM, derived from Kyber), FIPS 204 (ML-DSA, from Dilithium) and FIPS 205 (SLH-DSA, from SPHINCS+), concluding an eight-year selection process. Many read the headline, see the frequently cited year 2030 and put the topic back on the shelf. That is a misunderstanding: 2030 is a deadline, not a starting gun.</p> <h2 id="harvest-now-decrypt-later-makes-it-urgent">&ldquo;Harvest now, decrypt later&rdquo; makes it urgent</h2> <p>The threat does not wait for the first capable quantum computer. Attackers intercept encrypted traffic today and store it to decrypt later. Anything that must stay protected for a long time is therefore already exposed: contracts, health and HR data, long-lived keys, intellectual property, state and trade secrets. For this data, what matters is not when a quantum computer becomes practical, but how long the data must remain secret.</p> <p>With CNSA 2.0, the NSA sets 2030 as a mandatory deadline for national security systems. Germany&rsquo;s BSI has urged early migration and crypto-agility for years. Both describe a target, not a comfortable delay.</p> <h2 id="why-the-migration-takes-years">Why the migration takes years</h2> <p>Anyone who has tried to inventory their own cryptographic estate knows the problem: nobody knows exactly where which algorithms, keys and certificates are in use. On top of that come dependencies on libraries, hardware, protocols and partners that do not migrate to your schedule. A PQC migration is therefore not a switch but a multi-year programme.</p> <p>The path is clear in its order:</p> <ul> <li><strong>Inventory:</strong> make visible where which cryptography sits, including embedded and forgotten usage.</li> <li><strong>Prioritise:</strong> the long-lived data first, the data already exposed to the harvest-now risk today.</li> <li><strong>Establish crypto-agility:</strong> encapsulate algorithms so they can be swapped without changing the calling system.</li> <li><strong>Pilot hybrid:</strong> classical and post-quantum methods in parallel, to test interoperability and performance.</li> <li><strong>Automate and demand:</strong> automate renewal and bind suppliers to demonstrable PQC capability.</li> </ul> <h2 id="crypto-agility-is-the-real-lever">Crypto-agility is the real lever</h2> <p>The most common mistake is to see PQC as a one-time swap. The algorithms will keep evolving, parameters will be tightened, individual schemes could fall. What remains is the requirement to change algorithms without touching every calling system. Whoever builds in that agility today survives not only the first PQC wave, but the next one too.</p> <p>In our NextPKI module, exactly this is built in: crypto-agile from the start, RSA, ECDSA and Ed25519 today, post-quantum methods prepared, with policy per tenant. The point itself, though, is independent of any tool, namely to build agility as a property and not as a later migration.</p> <p>2026 is the year in which inventory and pilot should be in place. Then 2030 is merely the finish line, not a date to fear.</p>https://datargo.com/en/blog/e-invoicing-mandate-timeline/2025-02-11T00:00:00+00:002025-02-11T00:00:00+00:00

Receiving has been mandatory since January 2025, issuing follows in 2027 and 2028. What separates EN 16931, XRechnung and ZUGFeRD, and which format traps actually matter.

<p>Since 1 January 2025, e-invoicing in German B2B business is no longer optional. The first stage of the new mandate is in force: every domestic company must be able to receive structured electronic invoices. Issuing them electronically is not yet compulsory, but receiving them is. The legal basis is the Growth Opportunities Act (Wachstumschancengesetz), passed by the Bundesrat on 22 March 2024; the details are set out in the Federal Ministry of Finance guidance of 15 October 2024.</p> <p>More half-truths circulate around this obligation than around most tax topics. Three are worth clearing up.</p> <h2 id="myth-1-a-pdf-is-an-e-invoice">Myth 1: &ldquo;A PDF is an e-invoice&rdquo;</h2> <p>No. An e-invoice in the sense of the EN 16931 standard is a structured dataset that software can process without a media break. A classic PDF, even if it arrives by email, is merely an &ldquo;other invoice&rdquo; once the mandate applies. What counts is the machine-readable XML, not the image for the human eye.</p> <p>In Germany, two formats meet the standard: XRechnung, a pure XML following the CIUS of EN 16931, and ZUGFeRD from version 2 onward, a hybrid of PDF/A-3 with embedded XML. With ZUGFeRD, the XML leads, not the visible PDF. One important caveat: only the profiles from &ldquo;EN 16931&rdquo; (Comfort) upward are standard-compliant. The smaller MINIMUM and BASIC WL profiles carry too little data to count as a full invoice.</p> <h2 id="myth-2-it-only-matters-in-2027-and-only-for-big-companies">Myth 2: &ldquo;It only matters in 2027, and only for big companies&rdquo;</h2> <p>Receiving has applied to everyone since January 2025. Only issuing is staggered:</p> <ul> <li>since 1 Jan 2025: obligation to receive, for all domestic companies</li> <li>from 1 Jan 2027: obligation to issue, for companies with more than 800,000 euros prior-year turnover</li> <li>from 1 Jan 2028: obligation to issue, for all remaining B2B relationships</li> </ul> <p>Until the end of 2026, paper and unstructured formats may still be used by mutual agreement, and smaller issuers get an additional grace period until the end of 2027. Established EDI procedures remain permissible under conditions, but must move toward the standard. Whoever touches the issuing side only in 2027 still has a receiving task today.</p> <h2 id="myth-3-receiving-just-means-the-email-can-arrive">Myth 3: &ldquo;Receiving just means the email can arrive&rdquo;</h2> <p>Legally, an email address is enough for an e-invoice to be delivered. Operationally, that is half the job. Three things belong to it:</p> <ul> <li><strong>Validation:</strong> the incoming XML should be checked against the schema and business rules of EN 16931, otherwise faulty invoices land in the records unnoticed.</li> <li><strong>Visualisation:</strong> a viewer that renders the XML legibly, so departments without XML knowledge can review it.</li> <li><strong>GoBD-compliant archiving:</strong> what must be retained is the structured original, unalterable and chained in an audit-proof way, not just a PDF printout.</li> </ul> <p>The last point in particular is underrated. Whoever archives only the visual document and discards the XML has not retained the invoice in the legal sense.</p> <h2 id="what-makes-sense-now">What makes sense now</h2> <p>Receiving is mandatory and should be set up cleanly: validation, viewer, an audit-proof archive of the XML. In parallel, it is worth looking at issuing. Which customer relationships fall under the obligation in 2027, which formats do recipients expect, and how does the structured original leave your own system cleanly. In our commercial core Datargo ERP, EN 16931, XRechnung and ZUGFeRD, along with GoBD-compliant chaining, are built in from the start. The point itself, though, is independent of any tool, namely to treat the structured original as the leading record and not as an afterthought to the PDF.</p> <p>The obligation does not arrive in 2027. It began in 2025, just quietly, on the receiving side.</p>