Securing Emerging Technology Before It Becomes Legacy

Every technology you adopt early becomes legacy later, and its security debt comes with it. The cheapest moment to shape that debt is before the technology has an owner, a budget line and a chain of dependencies.

Legacy is not a matter of age. A system becomes legacy when it is embedded deeply enough that changing it means changing the business around it. That can happen within a year of a pilot starting.

How the debt builds

The pattern is familiar. A team trials something new with real data because test data does not show whether it works. The pilot succeeds, so it becomes a team tool. Other teams connect to it. Then it becomes something the business relies on. Security usually joins at that last step, when every control is a retrofit and every retrofit means asking someone to change how they work.

At no point in that story did anyone decide to accept the risk. It accumulated through a series of reasonable local choices. That is why emerging technology needs a different approach from mature technology: you cannot wait for a settled threat model, because by the time one exists, your estate already depends on the unsettled version.

Two places it is happening now

Agent integrations. Developers adopted protocols that connect AI agents to tools quickly, as they do with anything useful. The Model Context Protocol’s own security guidance now documents confused-deputy attacks, token passthrough, server-side request forgery and over-broad scopes. Those controls are cheap to build into the first few integrations. Retrofitting them into dozens of servers, each with its own authentication approach, is a different job. The agent-specific detail sits in our guidance on agentic AI security.

Cryptography. NIST has finalized its first post-quantum standards, FIPS 203, 204 and 205, covering key establishment and digital signatures, and has selected a further algorithm, HQC, for standardization. Its draft transition guidance sets a point at which RSA and elliptic-curve public-key algorithms are deprecated and a later point at which they are disallowed. The concern driving urgency for long-lived sensitive data is that traffic captured today could be decrypted if a capable quantum computer arrives. Nobody can say when. That uncertainty is a reason to plan now.

Cryptography shows the legacy problem clearly. Every system built today with a hard-coded algorithm, and every certificate and key buried in a vendor appliance, is a future migration. The security decision available today is cheap by comparison: find where cryptography lives, and make the algorithm something you can change.

Why the usual process misses it

Review processes built for mature products tend to fail on emerging ones in five ways.

• They review the product, not the pattern. Approving one agent platform says nothing about the next three, which share the same risks.

• Pilots get production data. The pilot label hides the exposure.

• Nobody defines an exit. Without retirement conditions, nothing is ever switched off.

• Ownership is vague. A shared experiment has no accountable person.

• The risk register has no line for it. If the threat model is unknown, the item reads “TBD” and stays that way.

A lighter gate at the pilot stage

A full security review of every experiment is unrealistic and teams will route around it. Five questions asked early are more likely to be answered honestly.

1. What can it reach? Data, identities and systems, including anything it could reach through another tool.

2. What does it decide on its own? Anything it can do without a person approving it.

3. What do we depend on that we do not control? Vendors, models, protocols, libraries, standards still in draft.

4. Which choices will be hard to undo? Data formats, identity design, hard-coded algorithms, logging gaps.

5. Who owns it, and what ends it? One named person, and the conditions under which the pilot stops.

Pair the questions with a tripwire: conditions that must be true before a pilot moves to production. Typical ones are that logging exists, the technology has its own identity rather than a borrowed one, data is classified, and a rollback has been tried. Decide the tripwire at the start, when nobody is invested in the answer.

Treat it as a watch, not only a project

You cannot predict which emerging technology will matter. You can keep a short, owned watch list. For each entry, record its stage (watching, piloting or adopted), whether a threat model exists, who owns the controls and when it is next reviewed. Draw on primary sources: standards bodies such as NIST and the IETF, OWASP, MITRE and the technology’s own security advisories. Move an item to a project when it moves to adoption, not before.

The AI-specific risks on that list are covered in more depth in our work on AI security controls and AI risk registers. The point here is wider: the same discipline applies to whatever comes next.

Design so that it can be removed

Architecture is where this pays off. If you cannot predict what will matter, make each new technology removable. Keep identity independent of any single vendor. Put an abstraction layer at integration points so a protocol or provider can be swapped. Use open formats for logs. Keep data portable. Make cryptographic algorithms configuration rather than code.

None of this stops legacy from forming. It lowers the price of dealing with it when it does.

Where to begin

Name the two emerging technologies your teams already use without a security review. AI agents are likely one. Run the five questions on each. The answers show what is about to become legacy in your environment, and what it would cost to change course now.

Sources

1. NIST, Post-Quantum Cryptography Standardization (FIPS 203, 204 and 205; HQC selection). https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization

2. NIST, Transition to Post-Quantum Cryptography Standards, NIST IR 8547, initial public draft. https://csrc.nist.gov/pubs/ir/8547/ipd

3. Model Context Protocol, Security Best Practices. https://modelcontextprotocol.io/specification/draft/basic/security_best_practices

4. OWASP GenAI Security Project, Top 10 for Agentic Applications. https://genai.owasp.org/owasp-top-10-for-agentic-applications