A small group of engineers is building protocols for the one transition the internet has never been able to acknowledge. The civil registry has been doing the same work, on paper, for two thousand years.

A small team of engineers is trying to solve a problem the internet has never dealt with: what happens to your accounts when you're gone. Paper-based government offices have handled this for centuries.

There is a room in every county seat in the United States, and in functionally every administrative jurisdiction in every country with a modern bureaucracy, where a clerk receives a piece of paper called a death certificate. The paper is signed by a physician, a coroner, a medical examiner, or in some rural districts a justice of the peace. The clerk logs it. The clerk assigns it a number. The clerk files a copy with the state registrar, who files a copy with the National Center for Health Statistics, which has, in the United States alone, received roughly six million vital-event records every year for the better part of a century. The protocol is bureaucratic. The protocol is slow. The protocol is, by the standards of the digital infrastructure that has grown up alongside it, embarrassingly analog.

In every county in America, a clerk receives a death certificate, logs it, gives it a number, and sends copies up the chain. This has happened millions of times a year for nearly a century. It works, but it's all paper and slow.

The protocol also works. When a person dies in Erie County or Cook County or Orleans Parish, the system knows. The Social Security Administration knows within days. The IRS knows. The bank knows, eventually. The DMV knows. The voter rolls know. The pension fund knows. A specific identity, attached to a specific human, is marked closed across every database that subscribes to the registrar's feed, and the closure propagates outward through a chain of administrative dependencies that was being designed before the founding of any nation currently using it.

When someone dies, every government and financial system that cares - Social Security, the IRS, your bank, the DMV - finds out and updates their records. One signed piece of paper triggers a chain reaction that closes the person's identity across every system.

There is no equivalent protocol on the internet. There is no clerk. There is no certificate. There is no propagating closure. When a person stops using a SaaS account, an OAuth grant, a session token, a federated login, an enterprise SSO seat, a forum membership, a published email address, the infrastructure those things sit inside does not learn that the person has stopped. The account persists. The token persists. The seat persists. The login keeps working until something else, usually an attacker, demonstrates that it was never actually closed.

The internet has none of this. When you stop using an account, the system keeping that account has no way of knowing. The account just sits there, still active, still working, until someone - often a hacker - proves it was never shut down.

A small group of engineers, distributed across standards bodies and academic labs and a handful of vendors, is trying to build the digital equivalent of the registrar's office. They do not, in general, describe their work that way. They describe it in protocol vocabulary. Account lifecycle management. Continuous access evaluation. Federation assurance levels. Deprovisioning signals. Risk incident sharing. The vocabulary obscures what the work actually is. The work is the construction, in code and in specification, of the closure protocol the internet was never built with.

A small group of engineers scattered across standards bodies and companies is trying to build a digital version of the government death registry. They use technical jargon to describe it, but the actual goal is simple: build a way to officially close digital identities.

Look at how the registrar's room works, because the mechanism is the thing.

Let's look closely at exactly how the government death registry works, because the details matter.

A person dies. A licensed practitioner, generally a physician or coroner, signs a certificate of death. The certificate is, in most US jurisdictions, a four-part document with specific data fields: decedent identifying information, cause-of-death sections completed by the practitioner, demographic data collected by a funeral director, and a registration block completed by the local registrar. The certificate gets filed within five days of the event in most jurisdictions. The registrar reviews it for completeness, assigns it a file number, transmits it to the state vital records office, and the state office in turn transmits it to the National Center for Health Statistics, which is the federal agency legislatively mandated to produce national health statistics and which has done this work continuously since 1902.

When someone dies, a doctor or coroner signs a form. That form has specific fields covering who died, why, and basic personal details. A local clerk logs it, numbers it, and sends it up the chain to the state and then to the federal government. This has been running without interruption since 1902.

The system is fault-tolerant by design. Parish records, state records, federal aggregation. Each jurisdiction is a full legal owner of the record, with its own retention schedule, its own format, its own signing authority. The chain of custody is statutory. The chain of dependencies, which runs through Social Security, the IRS, the voter rolls, the banks, the pensions, is event-driven. A single signed piece of paper, ratified by a local clerk, propagates outward to every system that has subscribed to the closure event. The system has been refined for roughly four hundred years in its modern form, longer if you count the late Roman census and the early ecclesiastical parish books.

The system is designed so that no single failure breaks it. Every level - local, state, federal - holds its own complete copy. And the moment that one signed piece of paper is filed, every system that depends on knowing someone is alive gets automatically updated. This design is hundreds of years old.

Now consider the analogous mechanism in identity infrastructure. There is none. There is no equivalent of the death certificate. There is no equivalent of the clerk who logs it. No state registrar propagates the closure. No dependent system has subscribed in advance. When a person stops being a customer of a SaaS application, the application does not know. When a person stops being an employee of a company, the SaaS applications the company federates with do not always know. Even when they do, the deprovisioning signal frequently fails to reach the application-level account that lives outside the SSO perimeter. The application keeps the seat. The seat keeps billing. The credentials keep working. The exploit surface keeps growing.

Digital identity has none don't know. Even when they're told, the message frequently doesn't reach the account itself. The account keeps running, keeps charging, keeps working as a potential entry point for attackers.

The internet has, in this sense, never crossed the threshold the civil registry crossed in 1538, when Thomas Cromwell, then Vicegerent for Spiritualities under Henry VIII, decreed that every parish priest in England would keep a register of weddings, baptisms, and burials. The decree was four sentences long. The decree was about taxes and about heirship and about who got to inherit property when a person stopped being alive. The decree was, in operational terms, the first protocol-level specification of a closure event in the Western administrative tradition. Five hundred years later, the protocol is still running. It has been extended. It has been digitized in parts. It has not been replaced.

The internet has never done what the English government did in 1538, when a royal decree required every parish priest to log births, marriages, and deaths. That four-sentence rule, created to track taxes and inheritance, was the world's first formal system for recording that someone had stopped being alive. It still runs today, five hundred years later.

The protocol the internet uses for the same closure event is: nothing. The session token simply continues to validate until its expiration date, which was set at issuance, which has nothing to do with whether the human it was issued to is still there.

The internet's current system for handling this is nothing. A login token just keeps working until the expiration date it was given at the start, regardless of whether the person it was issued to is still around.

What the working group writes

Here's what the engineers are actually writing.

There is a working group inside the OpenID Foundation called Shared Signals. The group has been operating since 2017. The output of the group is a small family of specifications collectively known as the Shared Signals and Events Framework, or SSE. The SSE framework has three principal profiles. RISC, the Risk Incident Sharing and Coordination profile, defines event types for sharing security incidents across cooperating systems. CAEP, the Continuous Access Evaluation Profile, defines event types for sharing access-evaluation signals so that identity providers can communicate "this session should be terminated" or "this account has been compromised" or "this user has been deprovisioned" to every relying application that has subscribed to the signal. SSEF, the underlying framework, defines how the events themselves are structured and transmitted as Security Event Tokens.

There's a group inside the OpenID Foundation called Shared Signals that has been working since 2017 to build three related systems: one for sharing security incidents between platforms, one for telling connected apps when a user's access should be cut off, and one underlying format for how all these alert messages get packaged and sent.

The chair of the Shared Signals Working Group is Atul Tulshibagwale, CTO of SGNL and a corporate board member of the OpenID Foundation. The group's work has been adopted by Microsoft, Cisco, Okta, and several other identity vendors. The December 2024 Gartner IAM CAEP Interop event in Dallas demonstrated, across roughly a dozen participating companies, that the protocols can in principle do what they are specified to do. The protocols can carry a deprovisioning signal from an identity provider to a relying party. The relying party can, on receipt of the signal, terminate the session, revoke the token, lock the account.

The group is led by the CTO of a company called SGNL and has been adopted by Microsoft, Cisco, and Okta. A December 2024 industry test event showed the technology actually works - one system can send a "shut this down" signal and the receiving system will close the session, cancel the token, and lock the account.

The adoption is a different problem. The 2024 Gartner event had a dozen participating vendors. There are, by industry analyst counts, over thirty thousand SaaS applications used in enterprise environments. Most of them do not implement CAEP. Most of them do not subscribe to RISC. Most of them rely on an internal account lifecycle that does not know what the identity provider's lifecycle is doing. An identity gets removed from Okta or Microsoft Entra ID. The application-level account in the SaaS tool, sitting outside the SSO umbrella, holding its own local credentials, maintaining its own session state, persists untouched. The deprovisioning signal was emitted. The signal had no subscriber.

But the adoption problem is huge. That test event had about twelve companies. There are over thirty thousand SaaS apps used in businesses. Almost none of them have implemented these protocols. So when an identity provider sends a "this person is gone" signal, most apps never receive it.

This is exactly the failure mode the civil registry was designed to prevent. When a death is registered in Massachusetts, the Social Security Administration does not have to remember to ask Massachusetts. Massachusetts pushes the event. The push is the protocol. The protocol assumes that any system with a legitimate dependency on the citizen's status is a subscriber, and the obligation to maintain the subscription belongs to the dependent system. The Massachusetts Registry of Vital Records and Statistics has been doing this work since 1936. The pattern is older than that. The dependency model is older still.

This is exactly the problem the civil registry was built to prevent. The government death registry doesn't wait for agencies to remember to ask. It pushes the notification out automatically. Every system that needs to know is required to be subscribed. The responsibility for staying subscribed belongs to the systems that depend on the information.

The SSE framework is, structurally, an attempt to install the dependency model into the federated identity system. The framework is the same shape as the registrar's office. The framework is missing the universal subscription. Until every application that depends on an identity is required, the way every state agency is required, to subscribe to the closure event, the framework is a protocol without a network.

The SSE framework is trying to be the digital version of that registry office. It has the right design. What it's missing is a rule that says every app that depends on a user's identity must be subscribed to receive closure events. Without that rule, it's a protocol with no one listening.

What NIST publishes

Here's what the national standards body is doing on this.

The other half of the work happens at the National Institute of Standards and Technology, in a series of documents that almost nobody outside the federal identity community reads but that quietly govern how most large American organizations implement digital identity.

The National Institute of Standards and Technology quietly publishes a document that most people have never heard of but that determines how most large American organizations manage digital identities.

The document is NIST Special Publication 800-63, currently in revision 4, published in July 2025. The 800-63 series is four volumes. The base document, 800-63, establishes the model. 800-63A covers identity proofing, the work of establishing that a person is who they claim to be at enrollment. 800-63B covers authentication and lifecycle management, the work of verifying that the person is still the same person session after session, year after year. 800-63C covers federation, the work of passing trust across organizational boundaries.

The document is called NIST SP 800-63, currently in its fourth version, published in July 2025. It comes in four parts covering the overall model, how you verify someone is who they claim to be when they sign up, how you keep verifying them session after session, and how you share that verification across different organizations.

The lifecycle management section of 800-63B is the relevant one. It contains, in normative language, the specification of what an identity system is supposed to do when an authenticator is revoked, when a credential expires, when a subscriber is deprovisioned, when a session must be terminated. The revision 4 publication, in August 2025, expanded the framework to align with continuous authentication and zero-trust principles. The named coauthors include Justin Richer, James Fenton, Naomi Lefkovitz, Elaine Newton, and a long list of others. The document is dense, current, and specifically engineered for federal procurement language. It reads, page by page, like a protocol designer trying to write a statute, which is roughly what it is.

The most relevant section covers what a system must do when a login credential is revoked, when it expires, when a user is removed, or when a session must end. The August 2025 update expanded this to cover continuous verification and zero-trust security. It's written like a legal standard because it's designed to be used in government contracts.

The work also does not have legal authority outside the federal sector. NIST publishes guidelines. The guidelines are normative for federal agencies and advisory for everyone else. State and local registrars operate under state statute; identity providers and SaaS vendors operate under whatever contract their customers were able to negotiate. The civil registry is mandatory because the legislature made it mandatory; the digital lifecycle is optional because no legislature has yet been willing to make it mandatory, and the industry has not, in the absence of legislation, voluntarily standardized.

But NIST can't actually force anyone outside the federal government to follow these rules. For everyone else, it's just a suggestion. The civil death registry is law. The digital identity lifecycle is optional. No legislature has forced the tech industry to standardize it.

This is the gap the engineers work in. They write specifications that have all the structural properties of a registrar's protocol. Event-driven. Push-based. Subscriber-managed. Dependency-aware. Propagating. They publish those specifications under the imprimatur of the Foundation or the Institute. They wait for adoption. The adoption arrives unevenly, in places, on the timeline of the surrounding commercial pressure. The specification is not the bottleneck. The bottleneck is that the closure event, in the digital architecture, is still optional.

This is the gap these engineers are working in. They write solid, well-designed standards. They publish them. They wait. Adoption comes slowly, driven by market pressure rather than legal requirement. The standard isn't the problem. The problem is that closing a digital identity is still a choice, not a requirement.

The people who do this work

Here are the people doing this work.

There is a small list of people doing the work, and the list has the same shape as every other small-list-of-people-working-on-an-invisible-problem.

There's a small group of people working on this, like every other important problem that most people have never heard of.

Atul Tulshibagwale, who chairs the Shared Signals Working Group at the OpenID Foundation. CTO of SGNL, which is one of a handful of vendors building actual implementations of the CAEP and RISC profiles. Tulshibagwale has spent the last seven years arguing, in technical writing and in conference talks, that identity lifecycle management is the largest unaddressed problem in enterprise security, and that the protocols already exist to solve it.

Atul Tulshibagwale runs the Shared Signals Working Group and leads one of the few companies actually building real tools based on these protocols. He's been making the case for seven years that this is the biggest unsolved security problem in enterprise tech, and that the tools to fix it already exist.

Justin Richer, an independent consultant and a co-author of the current revision of NIST SP 800-63B, who has spent twenty years writing the specifications that govern how identity actually works in federated systems. Author of OAuth 2 in Action. One of the more prolific protocol designers in the field.

Justin Richer has been writing the technical rules for how digital identity works for twenty years. He co-wrote the current NIST standard and literally wrote the book on OAuth 2, the system that controls how apps share login permissions.

The OpenID Foundation working group itself, with Mike Kiser, Jen Schreiber, Sean O'Dell, Omri Gazitt, and several others rotating in and out of leadership positions. The group meets weekly. The group has produced, in seven years, roughly eight specifications. The group has the cultural standing of a careful trade association and the technical standing of a small but well-respected research lab.

The OpenID Foundation working group has a rotating team of contributors and meets every week. Over seven years they've published about eight specifications. They operate like a small, careful, well-respected technical committee.

The CHAI researchers at Berkeley, in Stuart Russell's center, work on a different but adjacent problem. How to build identity systems that do not assume the user is still the same user, session after session, request after request. Continuous authentication. Behavioral re-verification. The conviction that proving who someone was at login is not the same as knowing who they are right now.

Researchers at Berkeley are working on a related problem: how to build systems that don't just trust that the person logged in right now is the same person who logged in originally. They want systems that continuously check, not just once at the front door.

A handful of academic researchers in privacy, in zero-knowledge proof systems, in selective disclosure protocols. A handful of vendors, including Okta, Microsoft, Cisco, SGNL, Aserto, Orchid Security, building implementations and trying to make them interoperable. Total population: small. Not as small as alignment. Larger than archival theory. The size of a discipline that has not yet been granted its own department at most universities. The people know each other. They read each other's specifications. They show up at the same handful of conferences and the same handful of standards meetings. The work, like the registrar's work, is mostly invisible until it fails. When it fails, the failure mode is a breach.

A handful of privacy researchers and companies are working on the broader ecosystem. The total community is small - well known to each other, working across a few conferences and standards meetings. Like the civil registry clerks, their work is invisible until something breaks. When it breaks, the result is a security breach.

What the lifecycle people understand that nobody else does

Here's what the people working on identity lifecycle understand that most people don't.

The move is that identity is not a static fact. Identity is a state. The state has phases. Provisioned. Activated. Active. Suspended. Deprovisioned. Each phase has its own access rules, its own evidence requirements, its own valid operations. Authentication is what happens within a phase. The lifecycle is what governs the transitions between phases. Most current identity infrastructure conflates the two. It treats login as the identity event. It treats the credential as the identity. It treats the user as a row in a database.

Identity isn't a fixed thing. It's a state that changes over time - created, active, paused, deleted. Authentication is what happens inside one of those states. Lifecycle management is what controls the moves between states. Most systems today treat logging in as the whole thing, treating the credential like the person, and treating the user like just a row in a spreadsheet.

The civil registry never made this mistake. The civil registry has always understood that a person passes through a sequence of states. Birth. Marriage. Divorce. Death. In some jurisdictions a small number of additional intermediate states like naturalization or change-of-name. Each transition is a documented event. Each transition has its own form, its own filing requirement, its own propagation pattern, its own downstream effect. The civil registrar does not maintain a single database of "people." The civil registrar maintains a ledger of events. The person is implied by the events. The current state of the person is the result of integrating the events.

The civil registry never made that mistake. It has always tracked people as a series of events - born, married, divorced, died - each one formally recorded, each one triggering its own updates across the system. The registry doesn't keep a list of living people. It keeps a record of events, and the person's current status is what you get when you add them all up.

This is, structurally, the same insight the lifecycle people are pushing into the digital identity stack. Identity is the integration of events. The current state is what you get when you replay the events. The session token is a single event in a long sequence. The provisioning record is another. The deprovisioning signal, if it ever arrives, is the closing event. The signed certificate, the signed assertion, the signed event token: these are the same shape as the signed death certificate the county clerk receives, and they want to be propagated through the same kind of subscription network.

The engineers working on digital identity are trying to bring this exact idea into technology, updated, transferred, closed - just like the civil registry. The session token, the account record, and the shutdown signal are all just entries in that event log. They want those entries to spread through a network the same way a death certificate does.

The technical term the field is converging on is "Security Event Token." The civil registrar's term, since 1538, is "register entry." The two terms name the same idea.

The technical world calls these events "Security Event Tokens." The civil registry has called them "register entries" since 1538. Both terms describe the same idea.

Why is this taking so long. Why is a specification that has all the structural properties of a four-hundred-year-old administrative protocol not yet universally deployed in 2026.

Why has it taken so long to adopt a system that mirrors something four hundred years old?

Why the protocol is still optional

The honest answer.

The honest answer is that the dependency is not yet legally enforced.

Because no law requires it.

When a citizen dies in any US jurisdiction, the death certificate is filed because the law requires it. The dependent systems, meaning Social Security, the IRS, the state DMV, the state pension fund, the federal voter database, the bank, the insurance carrier, subscribe to the registry feed because the law requires that too, or because the bank knows that if it does not subscribe it will eventually be on the wrong side of a fraud claim that the registry's records will resolve against it. The cost of failing to subscribe is higher than the cost of subscribing. The protocol works because the economics of non-participation are worse than the economics of participation.

The death certificate gets filed because the law says it must. Every agency that depends on knowing someone has died is required to subscribe to that information, or risks losing a legal dispute that the registry's records will settle against them. Complying costs less than not complying. That's why the system works.

The digital identity protocol has not yet crossed this threshold. The cost of failing to deprovision an account in a SaaS application is borne, primarily, by the customer of the SaaS application, in the form of a security risk that the customer cannot fully measure and that the vendor has no contractual obligation to mitigate. The cost of a missed deprovisioning signal is externalized. The vendor's incentive to subscribe to the CAEP feed is not yet aligned with the customer's interest in being deprovisioned cleanly. Until the dependency is enforced by regulation, by liability law, by insurance underwriting, by some other mechanism that prices the missing closure event, the adoption curve will continue to be uneven.

Digital identity has not hit that threshold. When a company's SaaS vendor fails to shut down an account, the company bears the security risk. The vendor has no legal obligation to fix it. There's no penalty for missing the shutdown signal. Until something - a law, a liability ruling, an insurance requirement - makes ignoring the signal expensive, vendors won't prioritize subscribing.

This is not a new pattern. The civil registry was not universally adopted in the United States until states began enforcing the registration requirement, and most states did not begin enforcing it seriously until the late nineteenth century, in response to public health crises. Cholera. Yellow fever. The epidemics that demonstrated the cost of not knowing who had died, where, of what. The trigger was a string of disasters. The disasters changed the economics. The economics produced the legislation. The legislation produced the universal subscription. Digital identity, at present, is in the pre-disaster phase. The closure events are missed. The dormant accounts persist. The exploit surface grows. The cost is real but distributed, and the distribution is fine-grained enough that no single actor has yet borne enough of it to demand the universal subscription that the civil registry has held since the late Tudors.

This isn't a new pattern. The US didn't get universal death registration until states started enforcing it in the late 1800s, pushed by cholera and yellow fever outbreaks that made the cost of not tracking deaths obvious. A disaster changed the math. The new math produced the law. The law produced the universal system. Digital identity is currently in the pre-disaster phase.

The specifications are ready. The working groups are ready. The vendors who have built implementations are ready. The thing that is not ready is the policy environment that would price the missing closure event high enough to force every dependent system to subscribe.

The technical work is done. The engineers are ready. The companies that built the tools are ready. What's missing is a policy environment that makes the cost of ignoring this problem high enough that every system is forced to participate.

The endpoint is the end. Point.

The end of a digital identity is, in fact, the end.

There is a phrase the field uses, sometimes, to describe what they are building: "lifecycle-aware identity." The phrase is honest. The phrase is also boring. The phrase obscures, with the polite mechanical vocabulary of protocol design, the fact that the work they are doing is the digital construction of a closure event. An architecturally honest acknowledgment, at the protocol level, that every digital identity will eventually need to be closed, that the moment of closure has to propagate, and that the propagation has to be mandatory rather than optional.

People in this field sometimes call what they're building "lifecycle-aware identity." It sounds technical and boring. But what it actually means is building a formal system to acknowledge that every digital account will eventually need to be shut down, that the shutdown needs to be announced, and that receiving the announcement must not be optional.

The civil registry got there first by a margin of approximately five centuries. The registry got there because the underlying social fact, that people are born, that people marry, that people die, was visible to the medieval state in a way that the digital equivalent has never been visible to the modern stack. The state knew that bodies stop. The state built a protocol for it. The state enforced subscription to the protocol because the cost of not knowing whose property to transfer, whose taxes to collect, whose name to remove from the militia rolls, was higher than the cost of building the registrar's office.

The civil registry got there five centuries earlier because governments could see that people die - it was an obvious, visible fact - and they knew the cost of not tracking it: property going to the wrong heirs, taxes not collected, men not removed from military lists. The cost was clear enough to justify building the system and making it mandatory.

The internet has not yet absorbed the same fact. The internet treats every issued credential as persistently valid until proven otherwise. The internet treats every account as a perpetual present-tense thing. The internet has no statute, no administrative culture, no mandatory protocol that requires it to acknowledge that the entity behind the credential has stopped existing in the relevant sense. The lifecycle people are building the missing protocol. The protocol is good. The protocol is technically ready. The protocol is waiting.

The internet still hasn't accepted this reality. It treats every login credential as valid forever unless proven otherwise. It treats every account as something that exists in permanent present tense. There is no law, no standard culture, no required process that forces the internet to acknowledge that the person behind an account may no longer exist in any meaningful sense. The engineers building the fix have a good, working solution. It's waiting for the world to require it.

In a registrar's room somewhere, a clerk is logging a death certificate this afternoon. The clerk has been doing this for thirty years. The clerk's predecessor did it for thirty years before. The clerk's predecessor's predecessor's predecessor, in some unbroken chain that runs back through state legislation and territorial statute and colonial law and parish register, was doing this work in 1632, and in 1538 before that, and in some form during the late Empire before that. The propagation works. The closure registers. The subscribers receive.

Somewhere right now, a clerk is logging a death certificate - the same work, in an unbroken chain, that has been done since 1538, and in earlier forms before that. The signal goes out. The record closes. The subscribed systems receive the update.

If a digital identity gets quietly stranded somewhere in a forgotten SaaS tenant tonight, who is going to log it?

If a forgotten account is silently sitting open in some abandoned software system tonight, no one is going to log it. There is no clerk. There is no certificate. There is no system waiting to receive the signal. That is the problem.