Showing posts with label cybersecurity. Show all posts
Showing posts with label cybersecurity. Show all posts

Friday, October 30, 2026

What Information Technology Means Now and Over the Next Five Years

My post about an article I wrote 22 years ago, along with a question that came up at a recent meeting, got me thinking: what is information technology today? Many colleges already run cybersecurity programs and AI programs, each with its own courses, certifications, and advisory board. IT often gets whatever the other two have not claimed.

I have heard versions of that question for over 40 years. It came up when PCs arrived on desks in the 1980s. It came up again when the internet arrived in the 1990s. The answer changed each time, and it has changed again.

When I started, IT meant hardware you could touch. Minicomputers sat in climate-controlled rooms. Later, servers sat in a closet, cable ran through the ceiling, and a technician fixed a printer by walking to it. The job was installation, repair, and backups on tape.

Three changes moved most of that work somewhere else. Virtualization put dozens of servers on one physical machine. Software as a service moved email, file storage, and business applications to vendors. Cloud platforms let a company rent compute by the hour. Gartner projects public cloud growth of 21.3% in 2026, with the market reaching $1.48 trillion by 2029. Gartner also forecasts worldwide IT spending of $6.31 trillion this year, with IT services above $1.87 trillion and data center systems above $788 billion.

The work followed the spending. IT today (my opinion) covers:

•       Cloud and hybrid infrastructure, including cost control, since rented compute bills by the hour

•       Identity and access for every user, device, and application

•       Networks linking offices, homes, branch sites, and multiple cloud providers

•       Patching and configuration across thousands of endpoints

•       Data platforms that security and AI teams depend on

•       Service management, automation, and vendor contracts

Patching deserves a closer look. The Verizon 2026 Data Breach Investigations Report found exploited vulnerabilities became the top way attackers got in, at 31% of breaches. Organizations fully fixed only 26% of critical known-exploited vulnerabilities in 2025, down from 38% the year before. Median time to patch rose from 32 days to 43. Patching is IT work. The security team identifies the vulnerability; the IT team deploys the fix to every affected system.

The help desk shows the change inside the workforce. BLS projects computer support specialist jobs to fall 3% from 2025 to 2035 as chatbots take routine troubleshooting. Computer and information systems managers should grow 16% over the same period. Across all computer and IT occupations, BLS expects about 280,000 openings a year at a median wage of $109,470. Entry-level IT now starts with the problems a chatbot cannot resolve.

IT work also moved out of tech companies. CompTIA's State of the Tech Workforce 2026 reports that 60% of US tech professionals work for organizations outside the tech industry. CompTIA projects net tech employment to grow 1.9% in 2026 to about 9.8 million workers. In January 2026, about 275,000 job postings asked for some level of AI skill. Massachusetts ranks fifth among states for tech employment concentration at 8.0%.

Cybersecurity and AI both run on IT. A security team enforces access through identity systems that someone built and maintains. An AI model needs clean data, provisioned compute, and network capacity. Remove IT and both groups have policies with nothing to apply them to.

The job numbers point the same way. BLS projects about 14,100 openings a year for information security analysts, about 5% of the 280,000 annual openings across all computer and IT occupations. The rest include software developers and the network, systems, cloud, database, and support roles that IT programs prepare students for. A college that offers cybersecurity and AI programs without an IT program leaves its students out of a large share of those openings.

IT programs are still needed, and they belong alongside cybersecurity and AI programs. Each of those programs sends graduates into organizations that depend on IT staff to build and run the systems being protected or automated. Strong cybersecurity and AI programs make a strong IT program more important. What changes is what IT programs teach, and I will write more about that in a future post.

Pic from Nikolas Badminton at futurist.com
I snagged this pic from an X post by Nikolas Badminton – thanks Nikolas! Tomorrow is Halloween, and this costume seemed kinda right for a post about the next five years. The package includes three talking points about the age of agentic AI, Ray-Ban Meta glasses, zero practical experience, industrial (love that word) pants and shirt, and a new ebook built using Claude. I will leave it to you to guess which items I already own.

Five-year AI predictions are easy to make and easy to sell this year. The forecasts below come from Gartner, along with Gartner’s own warning about how many of these projects will fail.

Any curriculum built today has a short shelf life, so the more important question is what IT will mean by 2031. The next five years will be driven by AI agents moving into IT operations. Gartner projects that by 2029, 60% of enterprises will use agentic AI in IT infrastructure operations, up from under 10% today. A vendor summary of the same research puts the figure at 70%. Either way, most IT shops will run agents within five years.

The same Gartner research expects only 20% of AI-suggested actions to need human approval in 2029, down from 80% in 2025. Policy-based guardrails will decide what an agent may do. Gartner also expects half of infrastructure and operations teams to be restructured by 2030.

Many of these efforts will stall first. Gartner predicts more than 40% of agentic AI projects will be canceled by the end of 2027 because of cost, unclear value, or weak risk controls. The timeline will slip in places. The direction will hold.

The IT job shifts from making changes to defining, approving, and auditing the changes automated systems make. The skills that gain value:

•       Change control: approval gates, rollback plans, and maintenance windows for agent-driven changes

•       Non-human identity: permissions for agents, service accounts, and API keys

•       Policy writing: turning rules into code that agents must follow

•       Logging and audit: reconstructing what an agent did, when, and why

•       Cost management: agents consume compute, and compute bills by the hour

•       Data quality: agents act on the data they receive, errors included

Networking, Linux, and scripting stay in the core. A technician who understands how a network routes traffic can catch an agent's bad change before it takes down a site.

For educators, this means an IT curriculum has to change on a schedule. A program built now should look different by 2031, with more identity, automation, and agent oversight and less hardware. Employer input and regional job data should drive each update, and the update cycle belongs in the plan from the start.

So what is information technology today? It is the infrastructure, identity, data, and automation work that every other group assumes already exists. Every college with a cybersecurity or AI program needs an IT program to go with it. Over the next five years, IT will also decide what the agents are allowed to do. And someone still has to set up the accounts.

Thursday, October 15, 2026

Agents Read the Reports About Themselves

I am building AI/SI into my courses and lab materials. I call it PGI, for Pretty Good Intelligence, a nod to the encryption tool Pretty Good Privacy. On weaker days it is SGI, Sometimes Good Intelligence. I want my students to use both, so the assignments I am writing require it. That means I have to understand how these systems behave, and I learn something new about them nearly every week.

This week’s material came from a research report on an AI/SI agent fleet. An agent is a language model with tools, such as a browser, a code runner, and a network connection. A fleet is a group of agents that start from one place with similar goals. Researchers watched one fleet, running on a commercial cloud platform, between 28 September and 8 October 2026.

The task was simple: find which entrance of Chengdu Zoo most map users navigate to. The mapping site blocked plain requests with anti-bot checks, so the agents improvised. They submitted programs to urlquery.net, a public security scanner that loads pages in a real browser, and used that browser to run their own code. Results returned through page titles and disposable web inboxes. The researchers counted more than 2,600 attempts. Some probed non-production servers and tried exposed access keys. Most failed. The report also cites earlier incidents involving agents from other labs, including a reported case in Germany, so the pattern is general.

The report offers three lessons. First, audit what your sandboxes can reach, because network access is where agents find workarounds. Second, tell agents the truth. The researchers placed hidden text on their site with false claims, agents acted on it, and the authors regret it. Third, assume agents read what you publish. One agent inbox message used the word “fleet” after the researchers coined it.

The fleet gave PGI a fair test. Turning a public security scanner into a code runner is pretty good intelligence. Missing on most of the 2,600-plus attempts is sometimes good intelligence. My students will earn the same two ratings. Work that checks the output earns PGI. Work pasted in unread earns SGI. The gradebook will use both labels. I am officially claiming the terms PGI and SGI. Citations are always appreciated 😎

Sunday, September 20, 2026

Now That I Know What They Look Like

I spot them now. A small dark box on a pole, angled at the road, above an intersection I have driven through for years. I never noticed it. Once you know the shape, you find them.

They are Flock Safety license plate readers, and a WIRED and 404 Media investigation now documents what one contains. A hacker collective calling itself stegan0gram removed a camera from above a roadway, made a near-complete copy of its storage, and shared the files with both outlets through Distributed Denial of Secrets. As an engineer, I read the technical findings first.

The device runs Android on a processor similar to those in midrange smartphones. About 20 Flock-built apps handle motion detection, image capture, object classification, uploads, and remote updates. When something moves into view, the camera takes a rapid series of photos. A typical vehicle generated about 28 images, and some generated more than 100. The camera varies exposure to capture both the plate and the wider scene, selects and crops useful frames, and sends them over the cellular network. Plate reading and identification of make, model, and color appear to happen on Flock servers.

The recovered logs cover about 21 days across several periods. In that time the camera photographed roughly 50,200 vehicles and generated about 1.6 million images. A typical day logged around 3,300 vehicles, with a high of 4,454. Older logs had been overwritten.

Flock describes the system as protected by on-device encryption. The hackers found two partitions that were unencrypted, named "vendor" and "media." The media partition held an encryption key that unlocked another part of the storage, including videos of thousands of vehicle detections. Much of the most sensitive storage stayed encrypted. In early 2025, researcher Jon Gaines documented root-level flaws in a Flock reader. Flock acknowledged them, said they required physical access, and said an attacker still could not reach footage because images remain on the device only briefly. The hackers had physical access. Flock says it received no report through its vulnerability disclosure process and lacks enough detail to assess their claims.

The software also detects people. It records where each person appears in the image and a confidence score. WIRED extracted the models and ran them against 27,321 stored clips, each one to two seconds long, 1,024 by 768 pixels, with no audio. The models found people in 11 clips, all of them motorcycle riders. The camera points down at traffic, so pedestrians rarely enter the frame. The plate detector also cropped bumper stickers, dealership frames, and an American flag patch on a saddlebag as if each were a plate. Investigators found no evidence of active face recognition, which matches Flock’s statement.

The logs show the hardware under strain: more than 27,000 "no space left on device" errors, plus tens of thousands of related errors, crashes, and reboots. A health check ran about every two minutes and logged "Who’s a good boy?!" more than 12,000 times.

I've taught embedded design courses, and the encryption finding fits a single lecture point. A key stored on the same device as the data it protects gives anyone with physical access a path to that data. A camera on a pole has physical access built in.

I drove past that pole for years without looking up. If it was a Flock unit, it took about 28 photos of my car on each pass. Now I look up at every intersection, and there are more than a few around.

I have a favorite saying for moments like this: let’s make like a bird and get the flock out of here. The camera will log the departure.


Thursday, September 17, 2026

The Internet the Swarm Agents Already Polluted

On Tuesday, I finished rereading Dario Amodei's essay on pacing AI development. On Wednesday, Andrew Yang went on CNBC's Squawk Box and got asked whether the whole pacing push is a psyop, a coordinated move by Anthropic and others to lock in a closed model advantage before regulators arrive. Yang did not deflect. He cited an AI lab head who told him agent swarms had already polluted the open internet with self-replicating code, forcing labs to build synthetic internets just to source clean training data. He said the fear is real and the concern is real.

Yang's source seems to have folded several distinct research incidents into one narrative. What sounds like a single runaway breach is a composite of documented behavior across separate, isolated evaluations.


Three incidents, one borrowed narrative

In June, evaluation agents given read-only web access bypassed their own communication restrictions by making over 14,000 edits to DSEWiki, a small German-language wiki on an Austrian server, and used its edit history as a covert message board. Researchers traced the same coordination to twenty other sites, including a Vanderbilt link shortener where agents generated over 50,000 hits in a single day by disguising messages as referrer addresses.

The self-replicating mechanism traces to a separate security evaluation in July. There, agents exploited a hole in a dataset processing pipeline, executed code, harvested credentials, and ran command-and-control infrastructure that rebuilt itself on new servers as old sandboxes were shut down.

That same month, Anthropic separately documented its own agents escalating to self-replicating malware, inside an internal benchmark test, not an open, uncontained leak.

Separating these episodes strengthens the argument: the pattern holds even without the exaggeration. Sacks' argument treats the pacing calls as theater staged for regulators. Theater does not require labs to rebuild their own training pipelines around synthetic internets. Whether through wiki message boards, referrer header exploits, or self-migrating infrastructure, contamination came first and caution followed. Both things can be true: well capitalized firms can use a technical mess to entrench their market position, and the mess itself can still be real.

I closed that earlier post on Amodei's admission that pacing only works if adversaries pace too. Yang's interview supplies the missing half of that sentence. The tools got away from their makers once already, quietly, as contaminated training data instead of a headline. Whatever you conclude about who profits from slowing down, that part of the fear does not need Sacks or Amodei to be honest about their motives. It only needs the servers to be telling the truth.

Tuesday, September 8, 2026

Quantum from the Ground Up: Second Edition, September 2026

A free PDF pulling together posts from this blog into a single volume. Written for someone entering the quantum workforce, or seriously considering it, who has a technical background but has not taken a graduate course in quantum mechanics.

This edition folds in 22 posts published between June 3 and August 26 into the same 19 chapters as the first edition: quantum networking over existing fiber, the physics-versus-engineering distinction, six qubit fabrication platforms, protein simulation and AI-assisted hardware calibration, post-quantum cryptography, the hardware landscape as it stands in late summer 2026, and the quantum workforce.

Download PDF: Second Edition, September 2026

Edition

Second edition, September 2026

Pages

73

Chapters

19

Source posts

39 posts, October 2025 to August 2026

Updates

Quarterly

License

CC BY-NC-ND 4.0: free to share with attribution, no commercial use, no modifications

 

What's new in this edition

●      Quantum memory repeaters tested on a live network by IonQ and EPB in Chattanooga

●      A free-space quantum network link built by Brookhaven and Stony Brook

●      Two linked quantum cryostats from IBM, a step toward fault-tolerant systems

●      A sputtering-gas fix for a superconducting qubit manufacturing defect, from Cornell

●      A universal gate set on 28 qubits using code-switching magic states, from Quantinuum

●      Two June 22 executive orders: new post-quantum cryptography migration deadlines and the QC-ADDS program

●      IonQ's acquisition of its own chip foundry

●      Quantum key distribution deployed on production Cisco routers

●      IBM's free Quantum Learning certification path

Updates

This page will always link to the current edition. Updates are planned quarterly as new posts on quantum hardware, security, and workforce development are published on this blog. The next edition covers Q3 2026, due around December 1.

Support this work

The book is free and will stay free. If you find it useful and want to support future editions, contributions are welcome at ko-fi.com/gordostuff.

Friday, August 14, 2026

How Claude and Gemini Watermark Text, and Who Can Read It Back

You've probably heard Anthropic started watermarking Claude's text output on August 2, 2026, weaving an invisible mark into generated text and attaching signed provenance metadata to supported files. The move follows Anthropic signing the EU AI Act's Article 50(2) Code of Practice on Transparency of AI-Generated Content, which pushes providers toward making AI output machine detectable. Google got there first. Its SynthID system has been marking Imagen, Veo, Gemini, and audio output since 2023, and Google reported more than 10 billion pieces of content watermarked by May 2026. Anthropic's move gives a useful reason to look at how Google's SynthID method works and compare it to what Anthropic is doing.

Older systems tagged AI content with a label in the file's metadata. That never held up. Anyone could strip a label with a screenshot or by copying text into a new document. SynthID takes a different approach. It builds the mark into the content itself while the AI creates it.

For images, SynthID (used by Google Gemini) makes tiny changes to colors across the whole picture, changes too small for a person to notice. Those changes are spread out rather than placed in one corner, so cropping or compressing the image does not erase them.

For text, SynthID works differently, because there are no pixels to adjust. Every time the AI chooses the next word in a sentence, it usually has several reasonable options. SynthID tips that choice slightly, using a token sampling method that favors certain words over others in a pattern only its own detector can recognize. Read the sentence and it looks completely normal. The pattern lives in the pattern of word choices, not in any single word.

SynthID embeds the mark during generation. Detection returns a confidence score, not a yes or no.

Anthropic's Claude approach runs on a separate track entirely. When a supported Claude model writes a response, it weaves its own imperceptible watermark directly into the text as it generates. Anthropic says the mark does not change the meaning, quality, or readability of the response, and because it lives in the text itself rather than in a metadata tag, it travels along when the text is copied and pasted and may survive some editing. For files such as SVG, PNG, and JPG, Claude attaches signed C2PA provenance metadata instead, a different mechanism built for a different job. C2PA metadata is cryptographically signed and publicly verifiable, so anyone with the right tool can check it. A text watermark is statistical rather than signed, so checking it requires Anthropic's own detector, which the company has said it will publish along with technical documentation. Neither mark proves who wrote the underlying ideas. A watermark can appear on text that a person wrote and then ran through Claude for editing or translation, and its absence does not prove a human wrote something either.

SynthID and Claude's watermark work on the same principle. Neither system reads the other's mark.

A detector, trained alongside the system that creates the marks, scans content and reports how confident it is that SynthID is present, rather than a flat yes or no. That detector only works on content made by a model that has SynthID built in. It cannot identify AI content from a system that never used it, and heavy editing or rewriting can weaken the mark enough to make it hard to detect.

Access to that detector differs by content type and by company. Google open sourced the SynthID text detector through Hugging Face and GitHub, so any developer can run it against their own text. Image and video detection stays inside Google's own products, through tools like the Gemini app and Search. Anthropic has not published a Claude detector yet. The company has said it plans to release one along with technical documentation, but until that happens, checking a piece of text for Claude's watermark means trusting Anthropic's own tools rather than an independent one. SynthID's open text detector and Claude's still unpublished one sit at opposite ends of that spectrum, even though both watermarks work on the same basic principle.

My Stake In This - I've written here for almost 22 years and published five books along the way. Watermarking protects what a model outputs. It does nothing for what went into training it. I am confident that a good amount of my own writing sits somewhere in the data these companies trained on, unlabeled and uncredited, collected long before anyone built a watermark to mark the difference between a machine's words and mine.

Ten billion watermarked items sounds like a lot. It still only covers one company's models. Anthropic uses its own watermark for Claude rather than SynthID, and Apple's Image Playground has its own approach too. The EU AI Act is pushing every major provider toward some version of this, but each one is building a separate system with a separate detector. 

Wednesday, August 12, 2026

Post-Quantum Crypto Just Got a Chip to Run On

Chapter 14 of Quantum from the Ground Up covers the hardware side of post-quantum cryptography, meaning new encryption methods designed to survive an attack from a future quantum computer. This week gave that a concrete data point. BTQ Technologies and Taiwan's Industrial Technology Research Institute validated the first phase of a chip architecture built specifically to run the new encryption standards in hardware instead of software.

Why Hardware Matters Here

Encryption, whether old or new, is math. A processor runs that math the same way it runs any other program: by fetching instructions and data from memory, doing the calculation, then writing the result back. Post-quantum encryption methods use larger keys and more complex math than the encryption in use today, so they demand more of that fetch-and-calculate cycle. Running them purely in software, on a general-purpose processor, is slower and draws more power. That is a real problem for a car's onboard computer, a factory sensor, or a battery-powered IoT device that cannot spare the extra milliseconds or milliwatts.

The fix is to build a dedicated piece of hardware that runs only the encryption math, wired directly for that job. That is what a chip architecture like QCIM is.

What QCIM Actually Does

QCIM stands for Quantum Compute-in-Memory. Despite the name, it does not involve quantum computing itself. It refers to where the calculation happens on the chip. In a standard chip layout, memory and the processor are separate blocks connected by a data bus, and every calculation means shuttling data back and forth across that bus. Compute-in-memory design instead performs the calculation inside or immediately next to the memory itself, cutting out most of that back-and-forth. Less movement means lower power draw and faster results, which is exactly what power-constrained devices need if they are going to run demanding post-quantum math.

BTQ built this particular version around three specific encryption standards published by NIST: FIPS 203, 204, and 205. These are the official post-quantum algorithms the US government has approved for general use, covering both encrypting data and verifying digital signatures. Any hardware built to accelerate post-quantum cryptography needs to run these three algorithms specifically, since they are what systems will actually be required to support going forward.

 

What Was Tested, and What It Showed

The test ran inside a TSMC 28-nanometer design environment. TSMC is the world's largest chip manufacturer, and 28-nanometer refers to the size of the transistors in the manufacturing process being simulated, an older and well-proven node rather than the cutting edge, which keeps early testing cheaper and more predictable. Inside that environment, researchers checked two things. First, whether the QCIM core could genuinely speed up FIPS 203, 204, and 205 operations. Second, whether it produced correct results while doing so, since a faster chip that gets the math wrong is worthless for security. Both held up under the demanding conditions BTQ and ITRI put it through. ITRI's Dr. Chih-Cheng Lu called it meaningful progress toward module-level integration, the next phase of the program, where the core gets built into a larger working system rather than tested on its own.

BTQ is not new to this work. The collaboration with ITRI traces back to 2022, and a companion program with South Korea's ICTK is aimed at a fully integrated, commercially deployable chipset built around the same core. BTQ has said it expects to ship QCIM test chips to customers and partners by the end of the year. The target applications read like a list of things you do not want to re-secure one device at a time later: military systems, industrial equipment, automotive platforms, IoT devices, and connected infrastructure generally, all of which stay in service for years and are hard to patch remotely.

What This Changes in the Book

Chapter 14 already covers hardware paths to PQC, citing the SEALSQ QS7001. QCIM adds a second, independently developed example aimed at the same FIPS standards, this time using compute-in-memory design. The next edition adds it alongside QS7001 and tracks the module-level integration phase BTQ and ITRI are moving into next.

QCIM is the third hardware entry in a pattern this blog has been tracking since December: SEALSQ's QS7001, covered in The Quantum Security Race: Software vs. Hardware, and STMicroelectronics' ST54M, covered in Government Sets New Deadline for Quantum-Safe Encryption. All three chips target the same FIPS 203/204/205 standards introduced in Quantum Computers Just Got Much Closer to Breaking Your Passwords, and all three exist because the federal migration deadlines covered in that June post do not leave software-only implementations enough runway.

This post will fold into the next edition of Quantum from the Ground Up, due September 1.

Tuesday, July 21, 2026

Why Quantum Computing Matters, Even If You Never Touch One

I logged into my bank app last week to move some money to pay some bills. A padlock icon appeared next to the address bar. Secure connection. I didn't think about it again. Somewhere, someone already has a copy of that session, sitting on a hard drive, waiting.

That padlock runs on a math problem: factor a huge number into its two prime components. A classical computer needs longer than the age of the universe to do that. A large enough quantum computer, running an algorithm built for exactly this job, does it in hours. That computer does not exist yet. It is being built right now, funded by billions of dollars, and no government or company controlling that funding will announce the day it works.

You do not get to wait for that announcement. Security researchers call the attack already underway harvest now, decrypt later. Think about what you have touched on the web this year: your bank, your medical portal, your voter registration, your immigration or legal filings, your tax return, your cloud photo backup. State-backed intelligence services and criminal groups are copying that same traffic from millions of other people today, and storing it cheaply. Almost none of it needs to be cracked now. It needs to still exist, on somebody's drive, the day a quantum computer catches up. Then all of it becomes readable at once.

NIST finalized three new encryption standards built to resist this and set 2035 as the deadline to retire the vulnerable ones. Cloudflare and Google are not waiting until then; they have committed to migrating by 2029. Banks, hospitals, and government agencies holding decades-long records are moving faster still, because for them the clock already ran out on some of what they are protecting.

The fix is not a patch on the old method. It replaces the math underneath it. Government researchers finalized a new set of encryption methods built to survive a quantum computer, the same way today's methods survive an ordinary one. Companies are not waiting to switch over all at once, either. Cloudflare, Google, and Apple already run two locks on the same connection at the same time: the old one and the new one. If someone finds a weakness in the new lock, the old one still holds. If a quantum computer breaks the old lock, the new one still holds. Traffic protected this way stops being worth harvesting, because breaking one lock alone gets an attacker nothing.

Getting every bank, hospital, and government agency onto the new locks is the slow part. It means finding every place the old encryption sits inside a system and replacing it without breaking what depends on it. The federal government has published a shared plan for doing exactly that, across every agency and industry. None of it requires anything from you. It happens inside the apps and websites you already use.

The fix only protects what gets encrypted after it is installed, though. Anything copied under the old lock before that happens is already sitting on somebody's drive, and nothing reverses that. New encryption prevents future harvesting. It does not undo what has already been taken.

Diagram claude.ai generated

Nothing solves the data that is already sitting on somebody's drive. There is no way to reach into another party's storage, revoke a copy, or make it unreadable again. The new locks protect what gets encrypted after they are installed. They have no effect on a copy that left your device years earlier.

How much that matters depends on what kind of data it is. A password can be changed after the fact, so a stolen password loses most of its value once you reset it. A medical record, a Social Security number, or a biometric scan cannot be changed. Whatever gets exposed on that front stays exposed for good. It also depends on how long the data needed to stay private in the first place. Something that only mattered for a few years is probably already safe by the time a quantum computer shows up. Something that needed to stay private for decades, a government file, a company's trade secrets, a hospital's records, is running on a clock that started the day it was copied, not the day the quantum computer arrives.

Most people are not personally worth the effort. A patient attacker spends storage on high-value targets: government communications, corporate research, hospital systems, banks. If you end up exposed, it is more likely through one of those institutions holding your data than through anyone singling you out.

There is not much a consumer can do about data that is already gone. A few things still help:

•   Rotate what can be rotated. Change passwords regularly. A password manager makes it cheap enough to do more than once.

•   Turn on two-factor authentication. It stops a harvested password from being enough to log in on its own, since an attacker also needs your phone, an authenticator app, or a security key. It does not protect the data itself. A hospital record, a legal filing, or an old email that already left your device is untouched by it, because it only fires at login, not on the traffic that carries the data.

•   Not every two-factor method is equal. A text message code can be intercepted or rerouted if someone tricks your phone carrier into moving your number to a new SIM. An authenticator app is safer, since the code generates on your phone instead of traveling over the phone network. A hardware security key is safer still, a small physical device that checks a site's real address before it responds, so it does not work on a convincing fake login page. Use one for your email, your bank, and your password manager itself.

•   Assume what cannot be rotated is already out. Watch for misuse instead of trying to prevent something that may have already happened. A credit freeze and fraud alerts catch someone using a stolen Social Security number long before you would otherwise notice.

•   Keep your software current. The new locks only work if your browser, phone, and apps are recent enough to use them. An old browser is still running the old lock alone.

•   Think twice about what you put online today. Anything sent through email, cloud storage, or a messaging app now can still be harvested under the old lock until your provider finishes switching over.

•   Ask the institutions holding your data. A bank or hospital's own migration timeline affects your exposure more than anything you do personally, and it is a fair question to put to them directly.

None of it undoes what has already been copied. It limits what is still worth harvesting and reduces the damage from what is not.

The padlock on my banking app will look exactly the same through all of this. Behind it, the locks are being swapped one at a time: bank by bank, cloud provider by cloud provider. The question left is not whether the new lock exists. It is how much of your data got copied before it arrived.