Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How to protect sensitive information in legacy applications?

Because a legacy system cannot be changed from inside, every control sits around it: segmentation and access enforcement in front, tokenization and encryption on its data flows, activity monitoring on the device, and substitution at the rendered screen. Treating the wrapper as the whole answer leaves the stored data, the platform and the application's own flaws unowned.

A legacy terminal sits inside an enclosure between an access gate and a tokenized modern application.

Because a legacy system cannot be changed from inside, every control sits around it: segmentation and access enforcement in front, tokenization and encryption on its data flows, activity monitoring on the device, and substitution at the rendered screen. Treating the wrapper as the whole answer leaves the stored data, the platform and the application's own flaws unowned. The defining fact about a legacy system is that its insides cannot be changed, so the controls go around it: network segmentation and access enforcement in front of it, activity monitoring on the devices that use it, tokenization of the data flows that pass through it, and, for agent work, render-layer tokenization of the screen the application presents. NIST's SP 1800-27 practice guide demonstrates the pattern end to end, protecting a property management system with network segmentation, point to point encryption, data tokenization, and business only usage restrictions implemented around the system rather than inside it (NIST, 2021). Each surrounding layer has a job, and each has a boundary, because some risks stay inside the application no matter how well it is wrapped. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • In NIST SP 800-207's terms, a legacy resource does not have to make its own access decisions: a policy enforcement point placed in front of it can govern access on its behalf (NIST, 2020).
  • NIST's SP 1800-27 reference design protected a working property management system, a classic legacy style hub, through stronger measures within and around it, including network segmentation, data tokenization, and role based access control (NIST, 2021).
  • Endpoint DLP monitors activities performed on sensitive items on the device, uploads, copies to removable media and network shares, and printing, which reaches data after it leaves a legacy application even when the application itself has no controls (Microsoft, 2025).
  • Endpoint monitoring carries two dependencies: the device must be onboarded on a supported operating system, and the detection layer must recognize the legacy application's exports as sensitive, through patterns, labels or exact data match (Microsoft, 2025).
  • A legacy application's rendered screen is its most standardized interface, and screen-level tokenization can govern what an automated operator is shown without any change to the application's code.
  • Wrapping has a hard boundary: controls around an application cannot repair the data stored inside it, the platform it runs on, or weaknesses in the application itself, and that boundary is part of the answer, documented in the gaps NIST's own guide leaves to replacement and risk acceptance (NIST, 2021).

What makes an application legacy in the ways that matter for protection?

Legacy is not a synonym for old. An old application that still receives security updates, exposes an API, and supports modern authentication is merely unfashionable, and it can be governed much like any other system. An application is legacy in the sense that matters here when some combination of the following holds: it cannot be modified, because the vendor is gone, the source is lost, or change would break a process the business cannot interrupt; it offers no API or connector through which modern controls can integrate; and it runs on platforms that are themselves out of support.

Each property deletes a category of protection. No modification means no agent inside the application, no field level masking written into its code, no logging added to its transactions. No API means the connected app route documented for modern SaaS, in which a platform such as Defender for Cloud Apps integrates with the application and inherits central policy, has nothing to connect to (Microsoft, 2025). An unsupported platform means even the operating system layer may refuse modern endpoint tooling.

What remains is everything outside the application's own code: the network paths that reach it, the identities and devices that access it, the files and messages its data becomes after export, and the screen it renders to whoever or whatever is operating it. The following sections take those in turn, because a legacy protection plan is the disciplined use of those four exteriors.

What can be controlled in front of the application?

Access is the first exterior, and zero trust architecture is the documented pattern for governing it without the application's cooperation. In SP 800-207, a subject's request to a resource passes a policy enforcement point, which acts on the decision of a policy engine and policy administrator; the resource is not required to evaluate the trust algorithm itself (NIST, 2020). Placed in front of a legacy application, that pattern lets the estate impose modern authentication, device checks, and per session authorization on a system whose own login may be a shared password from another era.

Segmentation is the companion control, and NIST's property management guide used it directly: the reference design implemented stronger measures within and around the system through network segmentation, restricting which systems and users could reach it at all (NIST, 2021). A legacy application reachable only from a small set of managed workstations, through an enforcement point, presents a radically smaller target than the same application visible across a flat network.

Neither control touches the data inside. They decide who and what may approach, and they log the approach, which for many estates is the single largest risk reduction available for a system that cannot be rebuilt. Access wrapping also fails soft in one important way: it does nothing about what an authorized user, or a compromised authorized session, does once inside. That is what the remaining layers are for.

What can be controlled around its data flows?

Legacy applications rarely keep their data to themselves. Records are exported to spreadsheets, printed to paper and PDF, emailed to partners, and copied into newer systems. Every export is a moment when the data leaves the unprotectable interior and enters territory where ordinary controls work again, and a serious plan inventories those flows rather than treating the application as a sealed box.

Tokenization is the strongest of the flow controls where it fits. NIST's practice guide protected the payment side of its property management system by tokenizing card data, so that the operational system and its connected processes worked with surrogates while the real values were confined to the payment solution (NIST, 2021). The generalizable version: where a downstream process needs a reference to a sensitive value rather than the value itself, substitute the reference at the boundary, and the downstream estate inherits protection it could never have implemented inside the legacy code.

Encryption in transit belongs in the same layer, and the guide paired it with segmentation as point to point encryption around the system (NIST, 2021). Flows that cannot be tokenized or encrypted, the nightly flat file to a partner running equally old tooling, should be named in the plan as accepted exposures with owners, because the most dangerous legacy flows are the undocumented ones nobody decided to accept.

What does the endpoint see after data leaves the application?

The device is the second exterior, and it sees the exports the moment they land. Microsoft documents endpoint DLP as auditing and managing activities users perform on sensitive items physically stored on Windows and macOS devices: copying an item to USB removable media or a network share, uploading it to a restricted cloud domain, printing it, and copying content into another application (Microsoft, 2025). None of those controls requires the source application to cooperate, be modern, or even be known to the policy. A file exported from a twenty year old claims system is a file on a device, and the activity rules apply to it on equal terms with any other.

Two dependencies apply. The device must be onboarded and running a supported system, which is a real constraint when legacy applications pin their users to aging workstations that cannot be upgraded without breaking the application. And the item must be recognized as sensitive, which for legacy exports often means the detection layer, patterns, labels, or exact data match, has to be taught what this application's output looks like (Microsoft, 2025).

Where the workstation cannot run the endpoint tooling, the fallback is to move the application rather than the control: run the legacy application in a hosted or virtualized session on infrastructure that can be monitored, so the device in front of the user becomes a display while the data stays in a governed environment. That pattern costs infrastructure and changes the user's experience, and it is sometimes the only way to get any observation point at all.

How did a NIST practice guide protect a legacy style system in practice?

SP 1800-27 is a documented build, not a theory. The National Cybersecurity Center of Excellence worked with the hospitality industry on the property management system, the operations hub of a hotel, holding reservations, guest profiles, preferences, and financial records, and connected to room key systems, point of sale, and guest networks (NIST, 2021). A PMS is the hospitality industry's legacy archetype: business critical, integration heavy, and effectively impossible to rip out.

The reference design's principal capabilities, as NIST summarizes them, were to protect sensitive data, enforce role based access control, and monitor for anomalies, achieved with zero trust concepts, moving target defense, tokenization of credit card data, and role based authentication (NIST, 2021). The documented process flows show access attempts directed to an access control platform, logged, and granted only the minimal access a role allows (NIST, 2021).

The transferable part is the ordering. The project did not begin by asking what the PMS could be made to do. It inventoried the risks around the system, theft of card data, privilege escalation, unauthorized use of personal information, and assigned each risk a control outside the application's code. Organizations with a legacy claims, billing, or records system can run the same exercise verbatim, substituting their own flows for reservations and room keys.

What can a render layer control do with a legacy screen?

The fourth exterior is the screen, and it has become more important as AI agents join the list of operators. A legacy application's screen is, paradoxically, its most standardized interface: whatever the code underneath, the record is presented as rendered text and fields, and an operator, human or automated, works with that rendering. Controls that operate on the rendering need nothing from the application itself.

That is the position RedactSure's published design occupies for agent workflows. Its supervised co-workers operate existing applications as rendered, with no per application integration, which is exactly the property a legacy estate needs, since integration is the thing its applications cannot offer. Values named by the Planner's screen level policy are presented to the model as tokens, real values resolving only at an approved destination for an approved action, and consequential steps wait for a named person. The result is that an agent can process work in a system older than the company operating it, without the model ever holding the values on its screens. The company describes deployments as in pilot, and this controls the agent's view, not the conduct of human users, which still depends on the access, flow, and endpoint layers above.

What risks stay inside the application itself?

Honesty about the boundary is what separates a legacy protection plan from a comforting story. Controls around the application do not patch it. Data at rest inside its database sits in whatever form the application chose, often unencrypted, behind its own aging access logic. A flaw in the application itself, reached by an authorized session through the enforcement point, is still a flaw. Credentials the application stores or transmits internally are its own affair. And the platform underneath, if unsupported, accumulates vulnerabilities no wrapper can fix.

Layer outside the application What it controls What it cannot do
Access enforcement and segmentation Who and what may reach the application, with logging Judge what an authorized session does inside
Flow controls, tokenization and encryption Data as it leaves for other systems and processes Protect the copy that stays in the application's store
Endpoint activity monitoring Files and content once they reach a managed device Run on devices the legacy stack cannot support
Render layer substitution What an agent is shown on the application's screens Govern human users, or the application's internals

The conclusion this forces is a program decision, not a technical one. Wrapping buys risk reduction and time, and the NIST example shows the reduction is substantial. It does not retire the underlying obligation, which is a dated, owned plan to replace, replatform, or formally accept the legacy system, with the wrapper's coverage statement attached as evidence of what the acceptance does and does not cover.

Where does RedactSure sit?

For the legacy screen itself, where an automated operator is shown records the application cannot mask, RedactSure's design puts the control at the render layer. AI co-workers work across an organization's applications inside a governed environment, with no per-application integration and no change to user permissions, so a system with no API and no vendor still qualifies. Every identifier chosen by policy is replaced by a consistent token before any model reads the screen; the model works with ACCT_001 and CARD_001 and receives the task's fields rather than a picture of the page. Real values return only at an approved destination at the moment of an approved action. The Planner sets which values are tokenized and what the agent may do on each screen; a named person confirms that policy and approves every payment, submission and record change under Supervised Delegation.

Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's own SIEM, an activity record the legacy system never produced on its own. Keys stay with the customer; the model is swappable. Deployments are in pilot. Human users still rely on the access, flow and endpoint layers. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

The page rests on NIST SP 1800-27, the NCCoE practice guide for securing property management systems (2021; official guidance); NIST SP 800-207, Zero Trust Architecture (2020; standard); and Microsoft Learn documentation on endpoint DLP activities and on DLP locations and connected app coverage (2025; vendor documentation). All sources were read as of October 13, 2026. NIST's statements are taken from the published guide and the architecture document as written; Microsoft's capability statements are taken from its documentation and dated. The property management system is used as a documented analogue for legacy systems generally, and differences between hospitality systems and other legacy estates, in regulation, data types, and threat model, are the reader's to map.

No legacy application was assessed or wrapped for this page, and no control effectiveness is measured or asserted. No hands-on testing of Microsoft Purview, Defender for Cloud Apps or any other named product was performed. Vendor and standards documents describe capability as designed; behavior in a specific legacy environment, especially on unsupported platforms, must be tested before it is relied on. Vendor features change, and the page carries its date and is revised when the documentation changes. The claims, billing and records examples describe system types, not any organization; no customer or prospect is described, and the RedactSure design is described at the level of its current published design, with deployments in pilot.

Whether a wrapper's coverage satisfies a regulator, an auditor or a contractual obligation is a determination for the organization's counsel, its assessor, and its security and compliance officers, not for a research page. The decision to replace, replatform or formally accept a legacy system belongs to the same owners.

What the record shows

A legacy application cannot be given the controls it was never built to have, so the protection moves to the four places that remain: in front of it, where an enforcement point and segmentation decide who may approach; around its flows, where tokenization and encryption govern the data as it leaves; on the device, where activity monitoring watches the exports whatever their source; and on its screen, where render layer substitution decides what an automated operator is shown. What they cannot do is repair the interior, the stored data, the aging platform, the application's own flaws. Wrap thoroughly, and write down exactly what the wrapping does not cover. The test is whether a dated plan for the system itself is attached to that coverage statement, so the legacy platform remains a managed risk with a paper trail and the decision about the system itself stays visible, dated, and owned.

Frequently asked questions

Can a legacy application be brought under central DLP policy at all?

Only at its edges, on the documentation reviewed. The connected app route needs an integration the application does not offer, and nothing can be installed inside it. What central policy can govern is everything around it: the endpoint activities performed on its exported files, the network paths that reach it, and transfers of its data once outside. A coverage statement for a legacy system should therefore list the application as governed at the device and flow layers, not as a policy location in its own right.

What is the first control to add around a legacy system?

Access, on the evidence of the NIST build. The SP 1800-27 reference design directed access attempts through an access control platform, logged them, granted only the access a role required, and segmented the network around the system. That combination shrinks the reachable population from anyone on the network to named roles on managed paths, before any data layer control is attempted, and it does so without asking the application to change at all.

Does wrapping a legacy application make replacement unnecessary?

No. Wrapping controls who reaches the system, what leaves it, and what an agent sees on its screens. It does not encrypt the data the application stores in its own way, patch the application, or support its platform. The correct use of a wrapper is to reduce risk while a replacement, replatforming, or formal risk acceptance is decided and dated. Treating the wrapper as the decision itself leaves the oldest risks in the estate permanently unowned.

Can tokenization work with a legacy application that has no API?

Yes, at the boundary rather than inside. NIST's practice guide tokenized card data so the property management system and its connected processes worked with surrogates while real values stayed in the payment solution. The substitution happens where data enters or leaves the application, in the flow, not in the application's code. For agent work, the same substitution can happen at the rendered screen, which needs no API either.

What happens when the legacy workstation cannot run endpoint DLP?

Move the application instead of the control. Endpoint DLP requires an onboarded device on a supported operating system, which a workstation pinned to an old application may not be. Running the legacy application in a hosted or virtualized session on monitored infrastructure turns the user's device into a display while the data and the observation point stay in a governed environment. It costs infrastructure and changes the user experience, and it is sometimes the only observation point available.

Can an AI agent work in a legacy application without the model seeing its records?

Yes, in RedactSure's current design, in pilot. The agent operates the application as rendered, and values named by the Planner's screen level policy reach the model as tokens such as ACCT_001, with real values resolving only at an approved destination for an approved action. A named person approves every consequential step. The application's code is untouched, and human users still rely on the access, flow and endpoint layers for their own activity.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.