PingCAP's report dates the revocation and leaves out the credentials' owner, age, and rotation history, so the useful exercise is reading Regulation 2024/2690 against your own register.
PingCAP began disabling stolen service account credentials on October 7, 2026, deleted more of them by October 10, and reported all identified ones invalidated as of October 14. I think a service identity's record should say, before a sequence like that starts, who answers for the identity, why it exists, and what would end it. A person's account gets much of that from employment. A token gets it only if someone writes it down on purpose.
PingCAP's report, dated October 19, says an unauthorized party "used stolen service account credentials to access certain PingCAP internal systems, copy data, and obtain source code." The window it gives is September 9 to October 7, 2026, which is 28 days. Those 28 days measure reported use. September 9 is not given as the date of the theft.
| Date (2026) | What the report says |
|---|---|
| Sep 9 to Oct 7 | Stolen service account credentials in use |
| Oct 7 | "became aware of the incident" and "began disabling the affected credentials the same day"; from this date, "disabled or revoked most affected accounts and credentials" |
| By Oct 10 | "deleted additional compromised credentials and removed excessive permissions between cloud projects"; additional cloud storage access logging enabled "in an affected project" |
| Oct 12 to 13 | External firm reports four vulnerabilities, all fixed by October 14; the report does not link them to the credentials |
| Oct 14 | "all identified compromised credentials have been invalidated, and the identified unauthorized access paths have been blocked" |
| Oct 19 | Status date for the work still continuing, including customer-specific impact |
An external firm reviewed PingCAP's production systems and "found no evidence that the attacker ran commands or maintained persistent access in the systems reviewed." PingCAP adds that this "does not change the data exposure." Exported records included user names and email addresses, SQL editor text and errors, customer contacts, and billing configuration. PingCAP says this does "not mean that every customer had every category of information exposed." One exported table "contained encrypted TiDB Cloud API-key values." The one investigator-owned value the external firm tested "could not be used directly as an API key," and whether other usable credentials were exposed is listed as open. As of October 19, PingCAP said it would notify affected customers "once we have established customer-specific impact." As of November 3, the page showed no status later than that.
The report does not state:
So the report does not show that these credentials lacked an owner or a leaver process. The incident is the occasion for this reading, and the reading has to stand without those facts.
The report says "service account credentials" and never says "token." I use "token" for the general class of credential you may hold yourself: a secret issued to a system so it can authenticate without a person present. I don't know what form PingCAP's credentials took.
Implementing Regulation (EU) 2024/2690 sets technical and methodological requirements for the measures in Article 21(2) of the NIS2 Directive, (EU) 2022/2555. Its Annex starts by treating both kinds of identity alike. Point 11.5.1 reads: "The relevant entities shall manage the full life cycle of identities of network and information systems and their users." Point 11.5.4 has them "regularly review the identities for network and information systems and their users and, if no longer needed, deactivate them without delay."
The two kinds separate at 11.5.2:
(b) link the identity of users to a single person; >(c) ensure oversight of identities of network and information systems;
A user's identity resolves to one human. A system's identity resolves to oversight, and point (c) says no more than that.
ENISA's implementation guidance (June 2025, version 1.0) fills in part of the gap. It recommends that non-human identities get "appropriately segregated approval and independent ongoing oversight" (p. 139). It also lists the minimum fields of an inventory record for each kind of identity (p. 138). Read this block as the change from a person's record to a service identity's record:
- person's name- username- start/stop dates+ department owner+ review date+ purpose level of privileges
Both lists are minimums, so nothing stops a team from adding an end date to a service record. As I read it, "department owner" names a department, not a person. A department can't hand in its notice, which keeps the field tidy. It also can't answer a question at review.
What follows is my reading, and neither text states it. Point 11.2.2(b) has entities "ensure that access rights are modified accordingly upon termination or change of employment." That clause covers access rights, and 11.5.4 is the deactivation clause for users too. Point 11.2.2(b) still gives a person's access a prompt from outside the register. Neither text gives a service identity an equivalent prompt for its own work ending. ENISA comes near it in places, for example a password change "upon termination or change of employment when a user has known passwords for identities that remain active (e.g. shared identities)" (p. 142), which changes a secret while the identity stays in place, and advice that decommissioning service providers consider "deactivating user and service accounts" (p. 71), which covers supplier exit only. Otherwise, what ends a service identity is the "no longer needed" decision in 11.5.4, or ENISA's example of removing dormant identities "after a predefined period of days of inactivity, where supported" (p. 140). ENISA puts the review at "as a minimum quarterly," or annually for micro-sized entities.
I don't think a review date replaces a leaver event. A leaver event arrives whether or not anyone is looking at the register, while a review date ends an identity only if someone reaches that date and decides the identity is no longer needed. That is why ownership of a service identity has to be assigned on purpose. I suspect most ISMSes haven't done this for their tokens. I have no survey behind that, so take it as a test to run on your own register.
Point 11.6.2(c) has entities "require the change of authentication credentials initially, at predefined intervals and upon suspicion that the credentials were compromised." This is a rule about credentials, where 11.5 is about identities. Changing a credential leaves the identity in place.
"Upon suspicion" is the trigger the timeline can be read against. PingCAP became aware on October 7 and began disabling credentials that day. The report says nothing about how it became aware, so nothing shows when suspicion could first have arisen. The trigger applies once someone suspects, and it has nothing to offer for the days before that.
"At predefined intervals" needs no suspicion, which is its value. Against a stolen credential, it helps only if a change falls inside the window of use and the old value stops working. An interval shorter than 28 days is certain to fall inside a 28-day window. A longer one may or may not, depending on when the last change came. Point 11.6.2(c) names no length, so the regulation leaves that choice to the entity. ENISA's guidance on the point (pp. 142-143) names none either, and it is written around passwords and users.
Rotation also assumes the theft doesn't repeat. If whatever exposed the old value also exposes the new one, the interval buys little. The report doesn't say how these credentials were stolen, so I can't say which case applies here. It does list "Expand credential rotation" under work continuing as of October 19. "Expand" may suggest some rotation already existed, but the report doesn't say so, and I treat the history as unknown.
An inventory records who answers for a credential. It says nothing about how the credential is being used. A token with a named owner, a recent review, and a clear purpose looks the same in the register on the first day of unauthorized use and on the twenty-eighth.
PingCAP's own list of fixes points the same way. Here is each line I can map, against the Annex point it benchmarks to. I've left out the disabling and deletion of credentials, which are incident response, though 11.5.4 also speaks of deactivation. I've also left out "access controls" and "code and secret scanning," because the report gives too little detail to place them.
| Report line | Annex point | Note |
|---|---|---|
| "removed excessive permissions between cloud projects" (by Oct 10) | 11.2.2(a), "need-to-know, least privilege and separation of duties" | Limits what a stolen credential reaches |
| "additional cloud storage access logging" (Oct 10) | 3.2.3(c), "access to systems and applications" | One affected project only |
| "audit logging" (continuing) | 3.2.3(c) and (d), "authentication-related events" | The list is qualified by "Where appropriate" |
| "alerts for unusual access and large data exports" (continuing) | 3.2.4, logs "regularly reviewed for any unusual or unwanted trends", plus alarm thresholds | The report doesn't say whether alerts existed before |
| "credential rotation" (continuing) | 11.6.2(c) | Current state unknown |
| Four vulnerabilities (fixed by Oct 14) | None of these points | The report gives no link to the credentials |
| Theft method, credential age, owner, inventory | None | The report is silent |
No row lands on 11.5. Ownership answers whose job a credential is. Least privilege limits what a stolen one can reach, and logs and alarms are where misuse could show up. A register that handles the first can record a token's level of privileges, but it doesn't limit them or watch for misuse.
I don't know whether a better record would have shortened the 28 days, or the time between October 7 and October 14. The report says all identified credentials were invalidated as of October 14, not when the last one was, and I won't guess. If you came for a finding that missing ownership caused this incident, the report can't support one.
I'm using the regulation as a yardstick for your ISMS. Art. 1 applies it to listed "relevant entities," from DNS service providers to trust service providers. Cloud computing service providers are on that list, and PingCAP sells a cloud database. Nothing I've cited says PingCAP is in scope, and I didn't check the territorial rules. I make no finding that it's covered or that it fell short of any point. If your organization isn't one of the listed types, it isn't a relevant entity under Art. 1. ENISA's fields carry less weight still. Its guidance says of itself: "This document is not legally binding and is only of an advisory character" (p. 3). Whether any of this binds you is a question for your counsel.
You don't need to go through the whole register to learn something from this. One real service identity will do. Check it against ENISA's four fields, then answer the question those fields leave open: what would end it?
In devguard, an organization token belongs to the organization rather than to a person and carries only the access you choose when you create it; its owner, purpose, and review date stay in your own record: organization tokens.
Vadim leads engineering, the architecture, automation, and integrations that let compliance live. He's set on making a serious, audit-grade system genuinely easy to run.
Start free, bring your frameworks, and keep the evidence attached as the work ships. No setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships. No setup friction, no audit-week fire drill.