Government Software Development

Regulation (EU) 2024/1183 amended eIDAS and created the European Digital Identity Wallet. The European Commission states that member states must provide EU Digital Identity Wallets to citizens by the end of 2026, and that service providers legally obliged to identify their customers unequivocally will be obliged to accept the wallet for authentication.

For a relying party that means four concrete workstreams: registration with the competent authority in your member state, including the exact attribute scopes you are permitted to request, since a wallet will refuse anything outside them; OID4VP presentation flows for same-device, cross-device, and offline use; credential handling for both SD-JWT VC and ISO/IEC 18013-5 mDL, because you do not get to choose the format the issuer used; and trust verification, meaning wallet attestation checks plus status list lookups for revocation.

The technical build is bounded, roughly six months for a focused team. Procurement in front of it is usually the longer half of the calendar, which is why scoping in 2026 matters more than building in 2027.

Directive (EU) 2016/2102 covers public sector websites and mobile applications. Per the Commission, bodies must publish an accessibility statement and provide a feedback mechanism, member states run regular monitoring and report to the Commission every three years, and harmonised standard EN 301 549 v3.2.1 gives presumption of conformity.

Two details decide whether a project passes. First, EN 301 549 is broader than a website: it reaches native mobile applications and published documents, so an untagged PDF library and an app that never had a screen reader pass are both findings. Second, conformance is evidence-based. A monitoring body asks what was tested, by whom, with which assistive technology, and against which success criteria. Teams that only ran an automated scanner have nothing to hand over.

We build the component library to the standard, test with keyboard and screen reader on real content, and deliver the audit trail alongside the software.

Public administration sits among the sectors of high criticality under NIS2, covered entities must address cybersecurity risk in supply chains and supplier relationships, and the reporting duty runs in three stages: early warning within 24 hours of becoming aware of a significant incident, notification within 72 hours, and a final report within one month.

That converts directly into build requirements for whoever writes your code. A software bill of materials for everything delivered. Static analysis and dependency scanning in the pipeline, not as an annual event. Documented remediation timelines by severity. Multi-factor authentication and least-privilege access as defaults. And logging designed backwards from the reports: if your team cannot assemble a defensible 72-hour assessment from the system itself, the logging design failed.

We treat these as architecture, not as a security annex written after handover, and we are happy to have them written into the contract.

Directive 2014/24/EU governs public tenders above the thresholds set for 2026-2027 by Commission Delegated Regulation (EU) 2025/2152: EUR 140,000 for central government supplies and services, EUR 216,000 for sub-central contracting authorities, and EUR 750,000 for Annex XIV services. Below those, national transparency and documented selection rules still apply.

Then the layers stack: GDPR data minimization and defined retention for every citizen record, national archiving law for anything with a legal retention duty, freedom of information retrieval, and the European Interoperability Framework pushing open standards and documented APIs so a neighboring agency can consume your data later.

None of that is paperwork. It is data architecture, and it has to be right early. Retrofitting a retention or audit model into a live registry is expensive precisely because the data model change drags documentation, approvals, and re-testing behind it.