Data sharing in Dutch education using the ECK iD¶
Nearly every pupil in Dutch primary education (PO), secondary education (VO) and vocational education (MBO) has an identifier that schools, publishers, distributors and learning platforms use instead of their name or citizen service number (BSN). It is called the ECK iD: a pseudonym of the BSN, generated by a central service called the Nummervoorziening. It exists so that schools and their suppliers can reliably share data about a pupil without passing around the BSN. This post explains why we have the ECK iD, how it is generated, who is involved, and what it does and does not protect.
The problem¶
Many different parties in the education chain process data about pupils. Schools buy learning materials from publishers, usually through a distributor, and pupils work with them on some platform, logging in through a login service. All of these parties need to know that the pupil the school ordered a license for, the pupil logging in and the pupil whose test results come back are the same person. Before the ECK iD, the only way to do that was to pass along information like name, date of birth, class, email address, or some system-specific ID. Matching on those can be unreliable or faulty (a pupil may have several email addresses for instance) or may break when a pupil switches classes, schools or systems. Using the BSN instead is not an option, because the law does not allow schools to use it for this purpose.
In late 2014, news reports drew wide attention to the fact that nearly all primary schools were sending pupils' personal data to Basispoort, a shared login server run by a foundation of the major educational publishers, who could link it to the pupils' results inside their learning environments. Around the same time that server turned out to have a security hole that had been known for weeks before it was fixed, during which pupils' login data could have been intercepted, at least for pupils on outdated browsers. Meanwhile, the ministry's own PwC baseline study on privacy and security in PO and VO had concluded earlier that year that schools collected far more pupil data than they could account for and had little grip on what their suppliers did with it. Parliamentary questions led to a debate in early 2015, and the direction that emerged was that the chain should stop passing identifying data around, and that a shared pseudonym should take its place.
So the requirement became: give every party in the chain a stable identifier for the pupil that is not the BSN and does not reveal who the pupil is, while still letting those parties agree that they are talking about the same pupil.
The ECK iD is the answer the sector settled on. Currently, it is broadly implemented in PO and VO, less so in MBO (and not at all in higher education), according to the 2024 statutory evaluation by KBA Nijmegen commissioned by the ministry. The VO learning materials chain agreed to use only the ECK iD from school year 2022/23, and the sector's agreement framework, Edu-V, treats it as the primary learner identifier.
How it works¶
The legal basis¶
The ECK iD is derived from the pupil's persoonsgebonden nummer (PGN), the number that identifies a learner in national education administration, in the Register Onderwijsdeelnemers (ROD). In practice the PGN is the BSN. When a pupil has no BSN, say a child who just arrived as an asylum seeker or a Belgian child at a Dutch school, the Dienst Uitvoering Onderwijs (DUO) issues a temporary onderwijsnummer and that becomes the PGN.
Schools were not allowed to use the PGN for communicating with the rest of the education chain, the education acts restrict what it may be used for. That changed on 1 February 2018, when the Wet pseudonimiseren van het persoonsgebonden nummer van een onderwijsdeelnemer (Kamerstukken 34741) came into force: a school may now use the PGN "once", to generate a pseudonym, which in practice became the ECK iD. Once means exactly that: the PGN is converted a single time, and every further identifier is derived from the resulting pseudonym, never from the PGN again. (Reporting enrolments to the ROD continues under its own legal basis.) The implementing regulation lists the sectors for which pseudonyms may be generated. Using the ECK iD is not mandatory. The sector organized adoption itself, with Edu-K, now Edu-V, a public-private program enabled by the Nationaal Groeifonds, as the platform where schools and suppliers agree on how the chain works.
Parties in the chain¶
Generating and using an ECK iD involves four kinds of parties.
The school's student administration system, or LAS (leerlingadministratiesysteem), holds the PGN. Think Magister, Somtoday, ParnasSys, ESIS, Eduarte. Only accredited LAS software may talk to the Nummervoorziening.
DUO, the government executive agency for education, holds the official enrollment register and has access to the population register (BRP). Schools already have to register every enrollment with DUO under the pupil's PGN, and that existing exchange is where the BSN gets verified.
Kennisnet, a foundation that acts as the ICT organization of the education sector, runs the Nummervoorziening. It holds no register of pupils, but provides the hashing service that generates the pseudonyms, and is trusted as a third party in that role.
The chain parties (distributors, publishers, learning platforms and test suppliers) receive only the ECK iD, and they receive it from the school. They never contact the Nummervoorziening themselves.
Computing the ECK iD¶
Take a fictional pupil, Sanne, who starts at a VO school that runs Magister. The hash values below are placeholders.
First, Magister registers Sanne's enrolment with DUO on behalf of the school, as it must for every pupil. DUO confirms that BSN 999998021 with her birthdate, gender and surname matches the BRP. Her PGN is 999998021.
Second, Magister hashes the PGN locally, as prescribed in Kennisnet's technical rules:
Kennisnet supplies the salt, and it is the same for every LAS in the country. The prescribed scrypt parameters are N = 2^17, r = 8 and p = 4. The same document says this costs roughly 130 MB of memory and about ten seconds on a single core of a Core i5 per hash, on purpose, to make building a lookup table unattractive. The output is 32 bytes, sent as 64 hex characters. This value is called the first-level hash, or HPGN.
Third, Magister sends the HPGN to the Nummervoorziening over mutual TLS with PKIoverheid certificates, following the Edukoppeling transaction standard, the education sector's profile of the government's Digikoppeling standard. Kennisnet applies SHA-512 with its own secret salt and returns the stampseudoniem, or root pseudonym, as described in the connection rules:
Fourth, Magister asks for a chain pseudonym by sending the HPGN together with a ketenId and a sectorId. Kennisnet derives the ECK iD from the root pseudonym and these two parameters, again with SHA-512 and its secret, and returns:
Fifth, Magister stores the ECK iD next to the BSN, encrypted, and hands it to the school's identity provider, to the distributor when the school orders Sanne's books, and to the publisher when she logs in to the method site, following the principles and processes agreed in the chain. All of them now hold the same ECK iD for Sanne. Only the school holds her BSN. When the publisher sends back her test results labelled with the ECK iD, Magister maps it back to Sanne.
The whole chain in one line:
Kennisnet publishes open source reference clients in Java and C# for the school side of this exchange.
Those strange URLs¶
The pseudonyms look like web addresses, but you are not supposed to visit them. The domain ketenid.nl is where the Nummervoorziening's public website lives, and it doubles as a namespace for the pseudonyms. The path segment is a version tag: spv1 means stampseudoniem version 1, and 201703 is the ECK iD definition from March 2017. It is the same trick as an XML namespace or a DOI prefix. The identifier is globally unambiguous, it says which scheme produced it, and if Kennisnet ever changes the hash or the secret, the new pseudonyms get a new prefix so that old and new cannot be confused.
The URL shape carries a small privacy risk. Pseudonyms that look like web addresses often get treated like web addresses too: a developer who runs into an ECK iD in a log file may paste it into a browser, at which point the pseudonym ends up in browser history, in sync services, and in the logs of the server behind ketenid.nl, now accompanied by the visitor's IP address. The W3C recognizes this problem: identifiers dressed up as URLs regularly get dereferenced, by software and people alike. Since ECK iDs are meant to stay inside system-to-system exchanges, and an ECK iD on its own tells an outsider nothing without the chain's data, the risk is limited.
Sectors and chains¶
Turning the root pseudonym into an ECK iD takes two extra parameters: a sectorId and a ketenId. The sector is what you would expect: PO, VO and MBO, with HO available on paper but never used. A pupil gets a different ECK iD in each sector. When Sanne moves on to MBO she gets a new pseudonym, and her old publishers cannot link the two. This gives some real privacy: what a pupil did in one sector does not follow them into the next, though the statutory evaluation notes that the boundary causes friction for pupils whose education straddles sectors, such as combined VMBO-MBO tracks.
A chain is a group of parties cooperating for one purpose (in current EU terminology: a domain), and the idea was that each such group could get its own pseudonyms for the same pupil. The explanatory memorandum explicitly foresees a separate ketenID for digital tests and exams and leaves room for further chains by decree. That never happened. There is one chain (a single domain), the educatieve contentketen, tests and exams use the same ECK iD, and Edu-V says outright that the ketenId is a fixed value.
What it delivers¶
Stable pseudonyms, no mapping tables¶
There is no randomness anywhere in the chain. The same BSN always leads to the same ECK iD, every time, on every system. If Sanne switches to another VO school that runs a different LAS, that LAS gets exactly the same ECK iD for her. Publishers see continuity across schools within a sector. That is arguably the main feature of the whole construction. A shared identifier within the chain could have been a random number issued by the school, but deriving the pseudonym from the BSN is what makes it survive a switch of school, LAS or platform, and Kennisnet advertises exactly that: no migration problems, because the ECK iD stays the same.
A nice operational benefit is that nothing needs to be stored to make the scheme work. Kennisnet does not need a table of pupils. It only operates a hashing service.
Privacy¶
The scheme also achieves some privacy. That privacy lies in unlinkability between identifiers, though the documentation does not specify a formal attacker or security model. Nobody except the schools should be able to link an ECK iD back to a BSN, or compute the ECK iD that belongs to a BSN, and nobody at all should be able to link a pupil's pseudonyms across sectors. The two hashing layers play different roles here.
The first layer, the scrypt hash at the school's LAS, is there mostly for legal reasons: the law gives the school, not Kennisnet, the right to use the PGN, so the school must be the one to transform it, and Kennisnet only ever sees a derived value. Cryptographically it offers less than it seems. The salt is shared with every LAS in the country, so it is not really secret and does not really prevent a dictionary attack: the valid BSN space is only about ninety million numbers, and at ten seconds per hash, computing all of them takes about thirty years on a single core, which is a few weeks on a few hundred rented cores, after which turning any HPGN back into a BSN is a lookup. That makes the table expensive, but not in a cryptographic sense, and Kennisnet's technical rules accordingly claim no more than that the heavy scrypt parameters discourage building it. So the HPGN has to be treated as BSN-equivalent data, and indeed it only ever travels over an authenticated channel to Kennisnet.
The secret at Kennisnet is where the actual unlinkability lives. Without it you cannot link an ECK iD and a BSN, in either direction, and you cannot link a pupil's PO ECK iD to their VO one. That holds even for DUO: it knows every BSN, but cannot compute a single ECK iD and never sees one. Notice, however, that the scheme itself does not prevent schools or LASes from requesting ECK iDs for arbitrary pupils: any party that may submit a hashed BSN gets the pseudonym back. Kennisnet cannot check whether a school requests ECK iDs only for its own enrolled pupils. So the Nummervoorziening only serves accredited school systems, authenticated with certificates.
The central choice of the design is to place the secret that all unlinkability depends on at one single party. If schools computed a keyed hash locally with a shared key, similar to how the HPGN is computed, a breach at any of a dozen LAS vendors would unmask every pupil in the country. Putting the keyed step at Kennisnet reduces that to a single point that can be guarded properly.
The stampseudoniem itself does not add any security to the data sharing in the chain. Its role is legal rather than cryptographic. In an earlier draft of the law, every chain pseudonym would be derived directly from the PGN, and the privacy regulator objected. Statutory person numbers such as the BSN and the PGN fall under a special regime in Dutch data protection law (article 24 Wbp at the time; when the GDPR replaced the Wbp, the rule moved to article 46 UAVG): such a number may only be used where the law itself, or a government decree taken by the cabinet as a whole, allows it, while the draft would have set the cases for new ketenIDs by mere ministerial regulation, a rule made by a single minister. The difference between those two instruments is nit-picky legal machinery, but it decided the design. The explanatory memorandum describes the fix: the PGN is used a single time to generate a root pseudonym, stored only in the school's LAS, and all ketenIDs are derived from that root. The pseudonym, unlike the PGN, is not a statutory person number, so new chains can be added by decree without touching the PGN. Arguably the HPGN is already such a pseudonym, but a far less secure one: anyone holding the shared salt can dictionary-attack it back to a BSN, which is impossible for the keyed hash at Kennisnet without the secret.
What it does not deliver¶
The ECK iD is not unlinkable between different parties in the chain. Everyone in the chain shares the same pseudonym. That is intentional, because the shared pseudonym is exactly what enables the data exchange between the parties. But this also allows any two parties in the chain to compare and combine their records about a pupil without any control, even when that is unauthorized (for example after a security breach), a risk the privacy assessment of the scheme itself flags. Better for privacy would be to give each party in the chain a different pseudonym, with a converter in between that translates one party's pseudonym into another's, because then every exchange has to pass through that converter, which can monitor and control it.
It is not anonymity either. In many flows the ECK iD travels together with identifying attributes, such as a name (so the software can say "Hi, Sanne!"), a class, a level, because teachers and pupils need to see who is who. The pseudonym takes the BSN out of the exchange, but it does not take the pupil's name off the screen. The law and the scheme's documentation do stress that the ECK iD should be stored separately from other identifying data wherever possible, but for any party that needs to know who is who, that separation is a bit of a paper measure: they receive the ECK iD precisely to attach it to a pupil, so name and pseudonym end up in the same record anyway. How much privacy is actually gained therefore depends less on the pseudonym than on the attributes that are shared alongside it and the actual anonymity or unlinkability in these cases is likely very limited. Education is not alone in this: in European eIDAS logins, the BSN becomes a pseudonym that travels together with the citizen's full name and date of birth.
It is also not blind. Kennisnet performs the keyed step on a value it can see. It does not see the BSN, but it does see a value from which the BSN can be recovered with enough computation. It also holds the secret that produces every pseudonym, and it sees every ECK iD it hands out, including which school requested it. Kennisnet is, in short, a trusted third party, and that trust is an assumption the whole scheme rests on.
A blind alternative¶
At NOLAI in Nijmegen we are developing PEP, polymorphic encryption and pseudonymisation, an alternative cryptographic technology that achieves stronger privacy guarantees through blind pseudonymisation. The idea is that everyone has a different identifier at each organization, and identifiers are only shared in encrypted form. To compute a pseudonym, a central transcryptor converts the encrypted identifier into an encrypted pseudonym that can only be decrypted by the intended receiver. The conversion happens entirely on ciphertexts, so the transcryptor never learns the identifier or any of the pseudonyms it produces, and even the sender does not learn the receiver's pseudonym. Using PEP, the central party is no longer a trusted third party in the way Kennisnet is because it never sees anything in the clear.
Because every party holds a different pseudonym for the same pupil, linking records across parties requires the transcryptor's cooperation rather than a comparison of two databases. And since the transcryptor takes part in every conversion, any data sharing can be monitored and controlled. Pushed to its extreme, this gives what we call micropseudonyms: pseudonyms with a deliberately small domain, shared by only the parties that need them.
This technology is implemented in the PEP responsible data sharing repository, which is used in healthcare research, among others by the Personalized Parkinson Project. A similar construction also runs at national scale in the Dutch eID scheme as BSNk, the register that derives polymorphic pseudonyms from the BSN for DigiD Hoog and eHerkenning, so that service providers may receive a pseudonym rather than the BSN itself. It is not widely used, though: today the pseudonyms mainly serve the eIDAS chain. The Wet digitale overheid, which would let service providers without BSN rights (such as private companies) accept DigiD logins under a pseudonym, is only entering into force in stages.
Applying PEP to education was proposed in 2015, for exactly the data sharing problem in this post, as a way to improve pupils' privacy: every supplier would get its own pseudonym for a pupil, rather than one shared identifier that the whole sector can link on. The education sector chose the simpler hash-based scheme instead, which does not require a converter being involved in every data exchange.
Similar systems¶
The ECK iD's architecture, a pre-hash at the source and a secret keyed hash at a trusted third party, is not an education invention. A similar system has been deployed for Dutch healthcare since 2007 by ZorgTTP, the foundation that pseudonymizes patient data for research registries. The parallel is close: the privacy regulator demanded that the first encryption happen at the data source, the step at the TTP stays secret from both sender and receiver, and every information chain gets its own pseudonym domain, with a controlled domain-conversion service for when two domains may be linked after all. The method was published at the health ministry's request in 2015 and the keys sit in an HSM, but the trust model is the same as Kennisnet's: one central party that everyone has to believe.
ZorgTTP's pseudonyms cover research, not care itself. In the care process the law works the other way around: the Wet gebruik burgerservicenummer in de zorg (since renamed to Wet aanvullende bepalingen verwerking persoonsgegevens in de zorg) requires providers to use the BSN, so that samples, results and files end up with the right patient, while using it for research is off limits.
What that identifying chain can cost was shown in the summer of 2025, when hackers stole the data of what turned out to be nearly a million women from Clinical Diagnostics, a laboratory that assessed samples for the national cervical cancer screening program. The lab held names, addresses, BSNs and test results side by side, so one breach at one subcontractor exposed all of it at once. The sequence, an incident at a supplier, parliamentary questions, and a public debate about why identifiable pupil or patient data moves through a chain, is strikingly similar to the one that set education on the path to the ECK iD in 2014. In a chain built like the ECK iD's, the laboratory would have known the sample and a pseudonym, but the mapping back to the woman would have stayed with the screening program, and the same breach would have yielded test results without identities.
Conclusion¶
The ECK iD is, at heart, a trusted third party scheme that hashes the BSN twice (or really three times): once at the school and twice at Kennisnet. This gives the education sector a stable pseudonym per pupil per sector, computable by any school system without mapping tables, that keeps the BSN away from suppliers. Kennisnet is a trusted third party that holds the secret all unlinkability relies on. However, since every party in the chain shares the same pseudonym, and names often travel along with it, the actual privacy gains are minimal. Blind pseudonymisation, as we develop with PEP, shows that neither the trusted party nor the shared pseudonym is necessary: the same data sharing can be done through a converter that sees nothing, with a different pseudonym per party, and with every exchange under control.
Disclaimer: the author is not affiliated with Kennisnet, DUO, Edu-K, Edu-V, OCW or any LAS vendor or educational publisher. This post is based on public documentation and reflects the author's own reading of it.