In the Treasury payment access dispute, “read-only” was a claim until the records proved it

The week

In early February 2025, the system that sends out most of the federal government’s money became the center of a national argument. It pays Social Security benefits, tax refunds and contractors, and it sits inside Treasury’s Bureau of the Fiscal Service.

The payment chain works in stages. Federal agencies prepare and certify payment files, and the Fiscal Service turns them into payments, mostly direct deposits through the banking system. Its systems therefore hold names, bank account and routing numbers and amounts for tens of millions of people. The first lawsuit described the bureau’s records as including Social Security numbers, birth dates, addresses and bank account information. Anyone who can read those files sees the federal government’s payments to individuals. Anyone who can write to them, or to the software that processes them, can in principle change who gets paid.

The background was two weeks old. On January 20, the President signed Executive Order 14158, which renamed the U.S. Digital Service as the U.S. DOGE Service and set up the Department of Government Efficiency. The order told agency heads to give it full and prompt access to all unclassified agency records, software systems and IT systems, consistent with law. It also said the service should adhere to rigorous data protection standards. Each agency was to form a DOGE team of at least four people.

It was widely reported that staff associated with the new Department of Government Efficiency had been given access to the bureau’s payment systems. A senior career official had left after reported disagreement over that access. Treasury told members of Congress that the access was “read-only,” meaning the people involved could look at information but could not change anything. Read-only is the difference between being allowed to read the ledger and being handed the pen.

That reassurance did not settle matters. On February 3, the Alliance for Retired Americans and two unions sued Treasury in Washington, D.C., arguing under the Administrative Procedure Act that the access violated the Privacy Act and exceeded Treasury’s authority. On February 6 the parties agreed an interim order. Access to confidential records was limited to Treasury employees doing their jobs and two named DOGE staff, whose access would be read-only.

Later in the week, nineteen state attorneys general filed their own suit in New York. On February 8 a federal judge there issued a temporary restraining order, an emergency court order that freezes a situation while the facts are sorted out. It limited access to Fiscal Service payment systems and data to career staff with a need, security clearances and training. Political appointees, special government employees and detailees from other agencies were excluded. Anyone newly excluded who had downloaded data since January 20 was to destroy the copies. Days later, the assigned judge narrowed the order to let Senate-confirmed Treasury officers back in. The revised order also exempted approved contractors doing routine or emergency maintenance, and the existing access of the Federal Reserve Bank of Kansas City.

Then came the detail that matters most for anyone who runs an important system. On February 11, a sworn declaration from a Fiscal Service deputy commissioner said that one staff member had been given read and write permissions to the Secure Payment System database. Treasury staff had found the previous week that his access was mistakenly configured that way instead of read-only, and had corrected it. According to the declaration, he had used the system only during a supervised walk-through session. A preliminary review of logs showed no sign of unauthorized use, and forensic analysis was continuing. “Read-only” had been the official description. The system itself, for a period, had said something different.

The politics of the episode were intense, and this article takes no side on them. What the week offered was something unusual: a public, sworn record of how access to a critical payment system is granted, described and checked. Most organizations only discover those mechanics in private, usually after something has gone wrong. Here they were laid out in letters to Congress, news reports and court filings for anyone to read.

Any organization that moves money or holds sensitive records faced the same uncomfortable test that week. If someone asked tomorrow exactly who can do what inside its most important system, could it prove the answer, or only describe it?

The dispute over access to Treasury’s payment systems was political, and this article takes no position on the policy. What makes it worth a leader’s time is rare public detail. Congressional letters, press reports and sworn court filings set out, in unusual depth, the mechanics of privileged access to a critical payment system. The record showed something every operator of an important financial system should take seriously. A statement about access, even an official one made in good faith, can turn out to be wrong, and only the systems and their records can settle the question.

The same pattern runs through almost every large organization. Somebody senior is asked who has access to a sensitive system. They ask a manager, who asks a team, who gives an answer based on what was requested and approved. Very often no one goes and asks the system itself. Most of the time the answers match. The Treasury episode is a public example of a time they did not.

The analysis below defines privileged access and its four controls, then takes each control in turn: eligibility, entitlement, evidence and authority. It closes with what the four put at stake, how a prepared organization documents them and how a leader can test them.

Master keys and who holds them

Every computer system gives its users permissions: rules about what each account is allowed to see and do. A customer service agent at a bank might be able to look up a customer’s balance but not move money. A payments clerk might be able to prepare a payment but not approve it. These everyday permissions are what keep a large organization from being a free-for-all.

Privileged access is the top tier of those permissions. It covers accounts that can do things ordinary users cannot: see large volumes of sensitive data at once, change how the system is configured, alter the software code that runs it, or initiate and change payments. In an office building, most staff have a badge that opens their own floor, while a few people, such as facilities managers and security staff, hold master keys. Privileged access is the master key, and privileged access governance is the set of rules about who gets one, what it opens, how its use is recorded and who decides.

A few other terms come up repeatedly in this story. Read-only access lets a user view information without changing it. Read and write access lets them change it as well. Least privilege is the principle that every account should have only the permissions it genuinely needs, and nothing more. Separation of duties means that no single person can both authorize something sensitive and carry it out, which is why a company cheque traditionally needed two signatures. And an audit log is the system’s own diary: an automatic record of who logged in, what they looked at and what they changed.

Privileged access governance rests on four controls, and each answers a different question. Eligibility asks who may be granted access. Entitlement asks what an account can actually do. Evidence asks what was done with it. Authority asks who may approve or refuse it. A weakness in any one undermines the others, and together they cover the life of a privileged account from request to review. The same four apply to a bank’s wire system, a processor’s settlement platform or a state treasury’s disbursement system.

Why payment systems raise the stakes

Payment systems differ from most record systems in one respect: their output is hard to take back. A wrong entry in a customer database can be corrected. A payment that has left for another bank may be gone. That is why payment operations rely on dual control, where one person prepares a payment and another releases it.

The 2016 theft from Bangladesh Bank’s account at the Federal Reserve Bank of New York showed what privileged access to payment messaging can do. Attackers used the bank’s own credentials and SWIFT connection to send fraudulent payment instructions, and about $81 million was diverted. Nobody needed to break the payment network itself. They needed accounts that the system trusted.

Configuration is the other route to money. Changing the bank account on file for a supplier, or the rules that decide which payments need a second approval, can redirect funds without touching any single payment. Fraud teams know vendor master file changes as a classic route for theft. Anyone who can edit that file holds a form of payment authority, whatever their title says.

Where the four controls already live

None of the four controls is new. Each already appears in the frameworks that regulated organizations follow, under different names.

• Federal systems. NIST Special Publication 800-53 covers account management, separation of duties, least privilege and protection of audit information, alongside personnel security controls for vetting.
• Banks and credit unions. The interagency information security guidelines, NCUA’s Part 748 and the FFIEC’s IT examination handbook expect access controls, monitoring and periodic access review.
• Institutions on the SWIFT network. SWIFT’s Customer Security Programme sets mandatory controls for its users, including restricting and protecting privileged accounts.
• Public companies. Sarbanes-Oxley audits test IT general controls, including logical access to financial systems and change management.
• Card data. PCI DSS requires need-to-know access, unique identification of users and logging of access to cardholder data.

Tax data adds another layer. Section 6103 of the Internal Revenue Code makes tax returns and return information confidential, and state agencies that receive federal tax information must follow the safeguards in IRS Publication 1075. A state revenue department’s disbursement system can therefore sit under several rule sets at once.

Eligibility: who may be granted access

Access to systems holding sensitive personal and financial data normally depends on conditions: a background investigation, employment or contractor status, training, signed agreements and a documented need. For federal systems, the Privacy Act and agency security policy limit who may access records about individuals. Banks apply similar conditions through policy and examiner expectations. These are the equivalent of checking someone’s references before handing over the master key.

Eligibility is easiest to contest when new categories of personnel arrive quickly, such as special government employees, detailees, consultants or advisers whose status differs from regular staff. Every organization has its version of this. A new chief executive brings in a small team. A private equity owner sends in operating partners. A transformation program hires a consulting firm with dozens of people who need to “see the data” by Monday.

Suppose a regional bank is acquired, and the new owner sends in a team of analysts to review the loan book. The bank’s policy says anyone with access to customer records needs a background check, privacy training and a signed confidentiality agreement. But the policy was written with employees in mind, and nobody is sure whether it applies to the owner’s people. The analysts are senior, the deadline is tight, and the request comes from the top. Exceptions get made informally at exactly this moment, and then become hard to explain later.

The fix is to define, in advance, how eligibility applies to each category, including temporary and advisory roles, and to require the same vetting, training and agreements regardless of seniority. When the rule exists before the request, the decision is administrative. When it does not, the decision becomes a dispute.

Eligibility by category

The New York restraining order shows how eligibility works when it is written down. It did not name individuals. It drew lines by category: career Fiscal Service staff with a need, clearance and training were in; political appointees, special government employees and outside detailees were out. A special government employee, under federal ethics law, is someone expected to serve no more than 130 days in a year. Whatever one thinks of where the court drew the lines, they could be applied mechanically to any account.

Federal agencies already have most of the machinery. Background investigations are tiered by the sensitivity of the position. Access to federal systems depends on a PIV credential issued after vetting. Users sign rules of behavior. The Privacy Act allows disclosure of a record within an agency to employees who need it to perform their duties. The gap, when there is one, tends to be in how these steps apply to people who arrive through unusual routes.

Other sectors have their own eligibility rules, set by law. Section 19 of the Federal Deposit Insurance Act bars people convicted of certain crimes involving dishonesty from participating in the affairs of an insured bank without regulatory consent. Broker-dealers must fingerprint personnel who have access to securities, funds or records under SEC Rule 17f-2. Agencies and vendors handling criminal justice information need fingerprint-based checks under the FBI’s CJIS Security Policy. Each rule applies to a specific type of organization, and counsel should confirm which ones reach a given role.

When vetting takes longer than the deadline

The strongest objection to strict eligibility is time. Background investigations take weeks. An urgent review, an acquisition or a fraud investigation may not wait.

The Treasury record shows the usual answer. The declaration described one person’s access as a supervised walk-through and another’s as “over the shoulder,” meaning a cleared employee operated the system while the newcomer watched. Supervised sessions, masked or synthetic data and pre-built reporting extracts let new people start work before full vetting, without giving them direct accounts. The later Social Security litigation described the same pattern: reviews typically began with anonymized data, and moved to identifiable records only for specific cases.

These interim arrangements carry their own risks. Over-the-shoulder access depends on the supervisor’s judgment and leaves a thinner log trail. Extracts become copies, and copies spread. The New York order’s requirement to destroy downloaded data showed how quickly a court treats copies as part of the access question.

Entitlement: what an account can actually do

In payment systems, the difference between reading data, changing configuration and initiating or altering payments is fundamental. So is scope. A reporting extract is a copy of selected data pulled out for analysis. Access to one differs from access to production databases, the live systems the organization runs on every day. It differs again from access to source code, the instructions that tell the system how to behave. Least privilege is the standard answer, but it only works when entitlements are precise and verifiable.

The Fiscal Service declaration illustrates the gap. The public statement described read-only access; the system had, for a period, granted more. That is a common failure in any large organization, and it rarely involves bad intent. Permissions are usually assigned through roles and groups rather than one by one. An account is added to the “analytics” group, and the analytics group, over years, has gradually accumulated rights that nobody remembers granting. Add to that the fact that the person describing access is rarely the person who configured it, and the room for honest error becomes large.

The control is an entitlement report generated from the system itself, showing the effective permissions of each privileged account, reviewed before access starts and after any change. “Effective” matters: it means everything the account can do once all its roles and groups are combined, which can go well beyond what was on the original request form. Two further points are easy to miss. Read-only access to a payment file still exposes sensitive data, such as names, account numbers and amounts. And access to code or configuration can create risk without any payment authority at all, because changing how the system works can matter as much as changing an individual payment. Both belong in the privileged tier.

How a read-only promise breaks

A modern payment system has several layers, and each has its own permissions. There is the application, which users see. Beneath it sit the database, the operating system, the network and, increasingly, a cloud console. An account can be read-only in the application and still hold write rights in the database underneath.

The common failure points are well known to administrators:

• Templates. A new account is copied from an existing one, and the existing one was an administrator.
• Nested groups. A group inside a group inherits rights that no one reviewed.
• Shared service accounts. A person is given the credentials of a technical account that was built to write.
• Emergency accounts. A break-glass account, meant for outages, is used for convenience and never disabled.
• Manual setup. A single checkbox chosen wrongly at provisioning time, which matches the declaration’s description of a mistaken configuration.

Controls that make entitlement verifiable

Several controls reduce the gap. Access can be granted from reviewed templates or code, so that a second person sees exactly what will be created. An automated comparison can check each account’s effective rights against the approved request and flag any difference within hours. Database-native read-only roles, or a separate read replica, make write access physically unavailable instead of merely unassigned.

Just-in-time elevation removes standing privilege altogether. An administrator requests elevated rights for a task, a second person approves, and the rights expire after a set period. Privileged access management tools record each session. The trade-off is friction. Operations staff who fix outages at night dislike waiting for an approver, and a badly designed process pushes them toward shared credentials. Approval paths for emergencies have to be fast, or people will route around them.

Access reviews are where examiners and auditors test all of this. A quarterly review in which managers tick a list of names proves little. A review in which the system owner sees each account’s effective permissions, certifies or removes them, and leaves a dated record proves a great deal. Sarbanes-Oxley auditors and bank examiners routinely ask for that evidence.

One objection is scale. A large bank may have hundreds of thousands of entitlements, and reviewing effective permissions for all of them is impractical. The answer is to concentrate effort. The privileged tier on critical systems is usually small enough to review properly, and it is where the damage would come from.

Evidence: what was done with the access

When access is challenged by a court, an inspector general, an auditor or a regulator, the organization must show who accessed what, when and what they did. That requires logs at the right level of detail, protected from tampering and kept long enough to answer questions months later. In the Treasury case, the government relied on a preliminary review of logs to state that the broader permissions had not been used, while forensic analysis continued. Without such records, no one could have said so.

The logs are the unsung part of this story. When the mistaken permissions came to light, the most important question was obvious: were they used? The only thing that could answer it was the system’s own diary. An organization without good logs, faced with the same discovery, could only say “we don’t believe anything happened,” which satisfies no judge, regulator or board.

Monitoring should flag unusual privileged activity: bulk data access, access outside normal patterns, new tools connecting to production, and any change to code or configuration. Production changes in payment systems should pass through change management, the formal process by which any alteration to a live system is proposed, reviewed by someone independent, tested and approved before it goes in. Logs of privileged sessions should be stored where the privileged users themselves cannot alter them. A diary that its subject can edit is not evidence.

Evidence also has a speed requirement. In a dispute, the organization may need to answer within days, not after a months-long forensic project. Pre-built queries that show, for any named account, every system touched and every record exported over a period turn a crisis into a report. Testing those queries once a year, as part of access review, confirms that the logs actually contain what the organization believes they contain. Many organizations find on first testing that a key system was logging far less than anyone assumed, or was deleting its logs after thirty days to save storage.

Read-only access needs read logging

A subtle point follows from the Treasury case. When access is described as read-only, the main risk is what was read and copied. Many databases, by default, record changes and logins but not individual queries. An organization that relies on default logging can prove that nothing was altered and still be unable to say what was viewed.

Database activity monitoring closes that gap by capturing queries, including the tables and volume of records returned. Session recording in a privileged access tool captures what an administrator did on screen. Both produce large volumes of data, which costs money to store and search. The logs also contain sensitive data themselves, so they need their own access controls.

What existing rules already require

Federal agencies have a specific benchmark. OMB memorandum M-21-31, issued in August 2021, set logging maturity tiers for agencies and required many log types to be kept for twelve months in active storage and a further eighteen months in cold storage. Organizations that store card data follow PCI DSS, which requires audit log retention of at least a year with recent months immediately available. Banks have no single retention number, but examiners expect logs sufficient to investigate incidents.

Retention and minimization pull against each other. Privacy rules push organizations to keep less data. Investigations push them to keep more. The workable answer is to keep security logs long, restrict who can see them, and record that choice in policy.

Preliminary review versus forensic proof

The declaration distinguished a preliminary log review from ongoing forensic analysis. The distinction matters to anyone who must make a public statement. A preliminary review checks access logs for obvious signs of misuse, often within a day. Forensic analysis reconstructs activity from several sources, checks log integrity and looks for gaps, and can take weeks. A statement made after the first should say so, and leave room for the second.

Authority: who approves, and who can refuse

In well-run payment operations, privileged access requires approval from a system owner who understands the risk and is separate from the requester. Separation of duties ensures that no one person can both authorize and exercise sensitive access. Career staff responsible for system integrity are usually the people applying these controls, and their job includes saying no, or “not yet,” when conditions are not met.

The episode showed what happens when the approval chain itself is in dispute, with formal authority on one side and system responsibility on the other. A senior official had left after reported disagreement over the access, and the question of who could decide moved quickly from an internal process to the courts. In federal agencies this intersects with legal questions for counsel and the courts. In private firms it is governance design that boards and audit committees should understand before they need it.

Take the corporate version. Suppose the chief executive of an insurer tells the head of IT to give a new strategy adviser full access to the claims system by the end of the day. The head of IT believes the request breaks the company’s own policy. If the answer to who prevails is “whoever is more senior,” the policy is decorative. Organizations should document who may grant privileged access to each critical system, how disagreements are escalated, and how each decision is recorded with its rationale. A short written record, made at the time, protects everyone, including the executive who made the request.

Formal roles in federal systems

Federal systems already assign authority on paper. Under the NIST Risk Management Framework, a system owner runs the system, an information system security officer manages its day-to-day security, and an authorizing official formally accepts its risk when granting an authority to operate. The agency head remains responsible for information security under FISMA. These roles determine who may approve access, but they do not settle what happens when a political leader and a system owner disagree.

Staff in that position have recognized channels. They can document the disagreement, escalate through the chief information officer and, where they believe the law is being broken, report to the inspector general. Federal whistleblower law protects such disclosures. None of those channels is fast, which is why written decision rights matter before a dispute starts.

Decision rights in banks and other firms

Banks typically use a three-lines model. The business and IT own the system and its access. A second-line risk or security function sets standards and challenges exceptions. Internal audit tests the result and reports to the audit committee. A credit union, a broker-dealer or a state treasury office will have a smaller version, but the same logic: the person who wants access should not be the only person who decides.

Dual control in payment release is the hard-coded form of this principle. The system will not release a payment unless a second, different account approves it. Privileged access to the system’s configuration should be treated the same way, because a single administrator who can change the approval rules can undo dual control.

The case for executive discretion

A fair objection is that leaders must be able to direct their organizations. A system owner’s refusal can be used to protect turf or slow legitimate change. New leadership often has good reasons to want fast, broad visibility.

The answer is a documented override in place of a veto. An executive with the authority can accept the risk in writing, name the compensating controls and set an end date. The system owner records the objection. Both positions survive, and so does accountability. What fails is an undocumented instruction, followed under pressure, with no record of who decided or why.

Money, liability and the people who say no

This is more than technical housekeeping: privileged access to payment and records systems bears directly on the things boards care about most.

• Money. Accounts with write access to payment systems can, in principle, change where money goes. Even the possibility of that, if it cannot be ruled out, can force costly investigations, payment holds and outside reviews.
• Legal and regulatory exposure. Privacy laws, banking supervision and contracts with customers all assume that access to sensitive data is controlled and provable. The Treasury episode moved from a policy question to sworn declarations within days. A private firm can find itself in the same position with a regulator or in litigation.
• Reputation and trust. Customers, citizens and counterparties rarely read entitlement reports, but they notice when an organization’s public reassurance is later corrected. The credibility cost of “we said X, the records showed Y” can exceed the cost of the underlying error.
• People. Staff who own critical systems need to know they will be backed when they apply the rules. Without a clear escalation path, the safest course for them is to comply without objection or leave, and neither is good for the institution.

How the exposure differs by type of organization

The balance among these four exposures depends on who is holding the system.

A federal or state agency faces the sharpest legal exposure, because Privacy Act claims, state privacy laws and court orders can arrive within days, as they did here. Its money risk is large in absolute terms but buffered by layered payment controls. Its reputational exposure is political as well as institutional.

A regional bank or credit union faces sharper money risk relative to its size, since a single fraudulent wire can be material. Its legal exposure runs mostly through supervisors, who will ask why controls failed and may require remediation. A broker-dealer adds books-and-records obligations, under which unexplained changes to records are themselves a problem.

A county or city treasury often has the thinnest staff. One or two administrators may hold most privileged accounts, which makes separation of duties hard to achieve. For these organizations, outsourced monitoring and a clear rule that no administrator can approve their own access often matter more than new tools.

Second-order effects

Disputes over access have downstream costs. Payment holds during an investigation delay legitimate payments to people who depend on them. Staff who see a colleague leave after objecting may stop raising concerns. And a public correction makes every later reassurance harder to believe, so the next statement has to come with evidence attached.

Documents rather than recollection

An organization in good shape can answer four things about any critical system quickly, with documents rather than recollection. It knows who is eligible, under rules written in advance. It knows what each privileged account can actually do, from a report produced by the system. It knows what each account has done, from logs the account holders cannot touch. And it knows who approved the access, with a recorded reason.

The failures are predictable, and most are made by well-meaning people under time pressure.

• Trusting the request form over the system. What was asked for and what was granted can differ, especially when access is given through broad roles.
• Treating read-only as harmless. Viewing a payment file can still expose personal and financial data at scale.
• Forgetting code and configuration. People who can change how a system works may not need payment authority to cause harm.
• Logs that exist but cannot be searched quickly, or that are kept too briefly, or that the administrators themselves can edit.
• Exceptions for seniority. The most senior requesters are often the least scrutinized, though their access tends to be the broadest.
• No written escalation path. When a system owner and an executive disagree, the absence of a process turns a judgment call into a confrontation.

Getting this right is less about buying new technology than about discipline. Many organizations already own tools that can produce entitlement reports and protect logs; the gap is in using them routinely and having someone accountable for reading the output.

A ninety-day sequence

An organization starting from a weak position can make real progress in a quarter, if it works in order.

1. Name the critical systems. Pick the few systems whose misuse would move money or expose records at scale, and assign each an owner.
2. Pull effective permissions. Extract the privileged accounts on each, from the system itself, and reconcile them against approved requests.
3. Fix logging. Turn on read logging where the data warrants it, and forward privileged logs to a store the administrators cannot change.
4. Write the eligibility categories. Cover employees, contractors, consultants, advisers and people brought in by new owners or executives.
5. Write decision rights. Record who may approve, who may object, how overrides work and where decisions are kept.
6. Test the queries. Ask for one person’s full activity history on a critical system and time how long the answer takes.

A few measures show whether the program is working. Useful ones include the share of privileged accounts whose effective rights match an approved request, the number of standing administrator accounts compared with just-in-time ones, and the time needed to produce one person’s activity history. These are internal measures, and each organization should set its own targets.

Testing whether the controls are real

A leader does not need to understand how permissions are configured to find out whether the controls are real. A handful of requests to the people who run the most important systems will show it.

1. For our three most critical systems, who currently has privileged access, and can you show me a list produced by the systems themselves rather than from our records of what we approved?
2. How do our eligibility rules apply to consultants, advisers, temporary staff and people brought in by a new owner or executive, and were any of them granted access as an exception in the past year?
3. If a regulator asked us on Monday what a named person did in our payment system over the past six months, how long would it take to answer, and when did we last test that?
4. Who has the authority to refuse a request for privileged access, how is a disagreement escalated, and where is the decision recorded?
5. When we last described someone’s access to a regulator, auditor or customer, did anyone check that description against the system before we sent it?

The last of these goes to the heart of the matter. The Treasury episode turned on the gap between a description of access and the access itself. Closing that gap, before anyone outside asks, is what turns privileged access governance from a policy on paper into something an organization can defend under oath.

A tabletop exercise makes the test concrete, and it costs little more than an afternoon of senior time. Give the team a scenario in which a court or regulator demands, within 72 hours, a sworn account of one outsider’s access to a critical system. Ask them to produce the eligibility record, the entitlement report, the activity log and the approval. Whatever cannot be produced in the exercise will not be produced under pressure either.

With hindsight

Litigation over access to Treasury systems continued well beyond that first week. Later in February 2025 the New York court granted a preliminary injunction in the attorneys general’s case, a longer-lasting court order than the initial emergency restraint. In subsequent months, access was allowed under conditions that included vetting and training: in effect, the eligibility controls described above, applied through the courts.

The court records show how that happened. On March 7, the New York court removed one software application from the restrictions altogether. On April 11, 2025, the court lifted the injunction for one DOGE team member after finding that Treasury had met requirements for his training, vetting, hiring, risk mitigation and reporting. On May 27 it refused to vacate the injunction, but allowed additional team members access if they followed court-specified training, vetting and mitigation procedures. The government appealed to the Second Circuit in July. As of late 2025, the modified injunction remained in place.

The Washington case went the other way on interim relief. On March 7, 2025, the court there denied a preliminary injunction. It found the plaintiffs had standing, but that the harm was not irreparable, because the disclosure was to a small number of people obligated to keep the information confidential. That reasoning made eligibility the deciding factor from the opposite direction: vetted, bound individuals reduced the harm a court would recognize. Cross-motions for summary judgment were still pending at the end of 2025.

Disputes over access to sensitive data then spread to other agencies, including the Social Security Administration, with courts reaching different conclusions. In June 2025 the Supreme Court stayed an order that had limited access to Social Security records, meaning that order was paused while the case continued. Members of Congress and privacy advocates kept pressing for accounts of what had been accessed and how it had been logged.

The order the Supreme Court paused is instructive in its own right. A federal court in Maryland had allowed DOGE staff access to anonymized or redacted Social Security data if they met the usual training and background-check requirements. Identifiable records were available for specific needs explained in writing. That is least privilege written as a court order. The full Fourth Circuit declined to stay it, by nine votes to six. The Supreme Court then allowed the agency to give its DOGE team access to the records while the appeal continued, so that team members could do their work. Three justices disagreed.

Throughout, whatever the legal outcome in a given court, the factual questions turned on the same four controls. The questions were whether people met the eligibility conditions, what their accounts could actually do, what the logs showed and who had authorized the access. Judges, lawmakers and advocates kept coming back to those points. They are the only ones that can be answered with evidence rather than assertion.

The cases also showed the limits of litigation as a control. Courts decided questions of law and harm, not whether access controls were well designed. Two courts looking at similar facts in the same month reached different interim results. An organization that waits for a judge to define its access rules has already lost control of the timetable, and of the facts that will be argued over.

Outside government, the episode’s lasting value was that it showed, in public and under oath, how quickly a question about access can escalate. A routine-sounding reassurance became a matter for sworn declarations within days. A configuration mistake that might, in another setting, have been fixed without notice became part of the public record. What saved the position, to the extent anything did, was that logs existed and could be reviewed.

The practical response is to prepare for scrutiny. An organization that can produce, on short notice, its eligibility rules, a system-generated entitlement report, protected activity logs and a record of who approved what is in a strong position whatever the dispute. One that can only describe its controls is relying on everyone’s memory being right. These four questions remain a practical test of privileged access governance for any critical payment system, public or private.