{"id":10134,"date":"2026-10-22T16:47:34","date_gmt":"2026-10-22T16:47:34","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=10134"},"modified":"2026-10-22T16:47:34","modified_gmt":"2026-10-22T16:47:34","slug":"building-zero-trust-across-healthcares-legacy-and-connected-environments","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=10134","title":{"rendered":"Building Zero Trust Across Healthcare\u2019s Legacy and Connected Environments"},"content":{"rendered":"
\n
\n
\n
\n
\n

Key Takeaways<\/h2>\n<\/div>\n<\/div>\n
\n
\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tHealthcare zero trust requires phased implementation that protects patient safety and clinical availability while reducing implicit trust.<\/span><\/p>\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tLegacy clinical systems can be protected through gateways and compensating controls when upgrades or agents are impractical.<\/span><\/p>\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tStrong identity controls, time-bound vendor access, and least privilege help reduce unauthorized access to critical systems.<\/span><\/p>\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tHealthcare network segmentation should follow traffic mapping, clinical engineering reviews, and carefully tested pilots.<\/span><\/p>\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tNetwork visibility, threat detection, and deception complement preventive controls by identifying suspicious activity across legacy systems and connected medical devices.<\/span><\/p><\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n
\n

Healthcare zero trust works when it\u2019s phased, ranked by risk, and tested against how care is actually delivered. A hospital can\u2019t pause an imaging suite to try a new access policy, and it can\u2019t swap out a clinical application because a framework prefers newer infrastructure. What it can do is remove implicit trust a piece at a time. Verify identity more carefully, limit which systems may talk to each other, watch what really crosses the network, and treat clinical availability as a design requirement.<\/p>\n

NIST describes the transition the same way. Its zero trust architecture publication[1]<\/a> calls it a journey that can\u2019t be completed by wholesale technology replacement, and it expects most organizations to run a hybrid of zero trust and perimeter controls for an indefinite period. Hospitals have extra reason to move carefully. FDA notes[2]<\/a> that cyber incidents have rendered medical devices and hospital networks inoperable, with delayed diagnosis or treatment as a possible result. This article covers where legacy healthcare systems and connected medical devices complicate zero trust in healthcare, how to phase the work, and where network visibility and threat detection<\/a> fit.<\/p>\n<\/div>\n<\/div>\n

\n
\n

Why Zero Trust Is Different in Healthcare<\/h2>\n<\/div>\n<\/div>\n
\n
\n

NIST\u2019s definition centers on dropping trust based on network location, so every request is judged on identity, device condition, and context. In an office, a misfired policy means a help desk ticket. In a hospital, it can cut a clinician off from a record or separate a device from the system collecting its readings. A healthcare zero trust architecture has to account for that, which is why patient data security<\/a> and clinical availability get weighed together.<\/p>\n

Hospitals also share the problem with manufacturers. FDA\u2019s February 2026 guidance is directed at medical device manufacturers and FDA staff. Its recommendations are generally nonbinding, although Section 524B of the Federal Food, Drug, and Cosmetic Act establishes statutory cybersecurity requirements for qualifying cyber-device submissions. The guidance calls cybersecurity a shared responsibility among facilities, patients, providers, and manufacturers, and it gives manufacturers an example threat-modeling assumption: hospital networks are hostile and an adversary may control them. Device makers already plan for an untrusted network. A hospital reducing implicit trust inside that network is heading the same way, and what the guidance asks manufacturers to publish becomes useful input for the hospital\u2019s own decisions.<\/p>\n

One distinction matters across healthcare cybersecurity guidance. HHS\u2019s HICP[3]<\/a> and its performance goals[4]<\/a> are voluntary and recommend zero trust and network segmentation. The current HIPAA Security<\/a> Rule remains in effect. HHS\u2019s 2024 proposal[5]<\/a> would strengthen requirements for MFA, network segmentation, and asset inventories, but no final rule has been issued, so it shouldn\u2019t be treated as current law.<\/p>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
Trusting Your Zero Trust Architecture with Fidelis<\/div>\n<\/div>\n<\/div>\n
\n
\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tDynamic threat monitoring<\/span><\/p>\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tProactive Cyber Defense<\/span><\/p>\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tZero Trust in Action<\/span><\/p><\/div>\n<\/div>\n

\n
\n
\n\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\tRead Whitepaper<\/span>
\n\t\t\t\t\t<\/span>
\n\t\t\t\t\t<\/a>\n\t\t\t\t<\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n
\n
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n
\n

Where Legacy and Connected Environments Create Zero Trust Challenges<\/h2>\n<\/div>\n<\/div>\n
\n
\n

Legacy clinical systems that can\u2019t change on demand<\/h3>\n<\/div>\n<\/div>\n
\n
\n

Legacy clinical systems running unsupported operating systems or vendor-locked configurations are hard to patch and hard to put agents on. FDA\u2019s guidance acknowledges the endgame for manufacturers: when a device stays in service past end of support, the maker should have a process for transferring risk to the user, and that risk grows over time. Where design fixes aren\u2019t possible, it recommends compensating controls.<\/p>\n

That\u2019s the opening zero trust security<\/a> in healthcare needs. If the asset can\u2019t change, the paths to it can. NIST describes an enclave model, with a gateway at the edge of a group of resources, for legacy applications that can\u2019t talk to a gateway themselves. The cost is coarser protection, since the gateway guards the group rather than each system. Around an aging clinical application, that\u2019s often a reasonable first step for clinical system security.<\/p>\n<\/div>\n<\/div>\n

\n
\n

Connected medical devices and IoMT security<\/h3>\n<\/div>\n<\/div>\n
\n
\n

A connected device isn\u2019t an island. FDA treats it as one piece of a system that includes the facility network, other devices, and update servers, and it asks manufacturers to consider attacks that could affect many patients at once, such as bedside monitors restarting together. That\u2019s why medical device cybersecurity and IoMT security depend on the surrounding network as much as on the device.<\/p>\n<\/div>\n<\/div>\n

\n
\n

Identity and access management beyond the clinician login<\/h3>\n<\/div>\n<\/div>\n
\n
\n

NIST counts applications and other non-human entities as subjects alongside people, and it flags automated agents as an open problem because they may authenticate with something weaker than MFA. Healthcare adds shared workstations, contractors, and vendors who maintain devices remotely. CISA\u2019s April 2026 OT zero trust guidance[6]<\/a>, which is general OT guidance rather than healthcare-specific, lists supply chain risk and identity and access management among its focus areas. MFA shows the tension: NIST warns that over-prompting users creates usability problems, and at a clinical workstation that friction has to be designed deliberately.<\/p>\n<\/div>\n<\/div>\n

\n
\n

Network visibility gaps and healthcare network segmentation<\/h3>\n<\/div>\n<\/div>\n
\n
\n

NIST expects a baseline before significant deployment: assets, subjects, processes, traffic flows, and dependencies cataloged. In hospitals those records can live with biomedical engineering, IT, and facilities separately. Encrypted traffic adds opacity, though NIST notes metadata and machine learning can still help flag malicious activity. Closing these network visibility gaps comes first.<\/p>\n

Healthcare network segmentation limits lateral movement<\/a>, and HHS lists it as an enhanced goal. It\u2019s also the change most likely to collide with clinical work. NIST says early deployments often deny requests that should succeed, so expect a tuning phase, and CISA\u2019s guidance stresses applying zero trust without disrupting the systems themselves.<\/p>\n<\/div>\n<\/div>\n

\n
\n

How to Build Healthcare Zero Trust Without Disrupting Clinical Operations<\/h3>\n<\/div>\n<\/div>\n
\n
\n

NIST\u2019s migration outline runs from identifying actors, assets, and key processes, through risk and policy for a candidate workflow, to deployment with monitoring, then expansion. Healthcare IT security<\/a> teams can use it as the backbone of their own zero trust implementation. Sequence varies. Weak remote access might put vendor access first, a flat device network might put segmentation first, and a team with decent controls but little insight might start with monitoring.<\/p>\n<\/div>\n<\/div>\n

\n
\n

Map workflows and dependencies, not just devices<\/h3>\n<\/div>\n<\/div>\n
\n
\n

For each workflow, record the systems it relies on, the accounts that touch them, the network paths between them, and what happens clinically if one goes down. Rank by patient-safety impact, exposure, and how exploitable the weaknesses are. Manufacturer labeling helps here: FDA says it may list network ports and destinations, a software bill of materials, and end-of-support information. A hospital can request those documents and treat them as inputs. NIST suggests starting by use case, so pick one workflow with a defensible scope.<\/p>\n<\/div>\n<\/div>\n

\n
\n

Tighten identity where change is possible<\/h3>\n<\/div>\n<\/div>\n
\n
\n

Start with the most privileged and exposed access: administrator accounts, remote access, and service accounts. Give shared and service credentials owners, and retire the ones nobody can explain. Apply least privilege access where the workflow can absorb it, and test the login experience with clinical staff first. Where a legacy application can\u2019t handle modern authentication, put the control in front of it.<\/p>\n<\/div>\n<\/div>\n

\n
\n

Treat vendor access as its own project<\/h3>\n<\/div>\n<\/div>\n
\n
\n

Vendor reach tends to be broader and longer-lived than the task needs. Define what each vendor requires, route access through a controlled path with named accounts and MFA, and make it time-bound where operations allow.<\/p>\n<\/div>\n<\/div>\n

\n
\n

Segment by function, then validate with clinical engineering<\/h3>\n<\/div>\n<\/div>\n
\n
\n

Begin with coarse zones, such as device networks apart from user and administrative networks, and tighten only where evidence supports it. Before enforcing a rule, watch real traffic, compare it with manufacturer-documented flows, and review the draft with clinical engineering. Some devices need their connections to do their job, so isolation is a joint decision, not a security ticket. Where a device can\u2019t be changed, compensating controls such as limiting what can reach it are the practical option.<\/p>\n<\/div>\n<\/div>\n

\n
\n

Pilot, tune, and expand<\/h3>\n<\/div>\n<\/div>\n
\n
\n

Treat each change as a pilot with a rollback plan and an agreed downtime procedure. Tolerance for wrongly denied access should be low in clinical areas. Expand once behavior is stable and clinicians confirm workflows are intact.<\/p>\n<\/div>\n<\/div>\n

\n
\n

An illustrative example: one imaging workflow<\/h3>\n<\/div>\n<\/div>\n
\n
\n

This is a hypothetical walk-through, not a documented customer deployment. Imagine an older imaging archive running an unsupported operating system, a connected scanner, a few viewing workstations, and a vendor who services the scanner remotely.<\/p>\n

The team first lists those systems and gathers the manufacturer\u2019s documented ports and update paths. Next it maps which systems must talk to which: scanner to archive, workstations to archive, vendor to scanner. Vendor access then moves behind a controlled path with named accounts and MFA, and the archive gets a gateway in front of it because it can\u2019t be changed itself. The team observes traffic for a period, compares it with the documented flows, and only then writes segmentation rules that permit those flows. Monitoring flags anything outside them, such as a workstation connecting to the scanner directly. Before enforcement, clinical engineering runs a full scan-to-viewer cycle in a maintenance window with rollback ready. Each step is small, and each answers one specific risk.<\/p>\n<\/div>\n<\/div>\n

\n
\n

Where Network Visibility and Healthcare Threat Detection Fit<\/h2>\n<\/div>\n<\/div>\n
\n
\n

Access controls and segmentation encode what should happen. Network visibility<\/a> and healthcare threat detection show what does happen. NIST\u2019s tenets include monitoring asset posture and collecting as much data as possible on assets, traffic, and access requests to improve policy. NIST also says a well-built architecture reduces risk without eliminating it, because someone holding valid credentials can still reach what that account is allowed to reach. Detection is how misuse inside permitted access gets noticed, and behavior-aware approaches are likelier to catch stolen credentials.<\/p>\n

Detection also tests the controls. Traffic between segments that shouldn\u2019t communicate means a rule is too loose, a device is compromised, or a dependency went undocumented. It doesn\u2019t replace prevention, though. Watching an unsegmented network with shared administrator credentials leaves the exposure in place, and no healthcare zero trust program is complete without both layers.<\/p>\n<\/div>\n<\/div>\n

\n
\n

Where Network Detection and Deception Fit<\/h2>\n<\/div>\n<\/div>\n
\n
\n

Zero trust is assembled from many tools, and NIST\u2019s 2025 practice guide[7]<\/a> built 19 example architectures with 24 vendors to show it. Fidelis products sit in the detection and verification layer. They don\u2019t set access policy, manage identities, or enforce segmentation, and they don\u2019t make an organization HIPAA compliant.<\/p>\n

Fidelis Network<\/a>\u00ae gives teams visibility into traffic that access controls can\u2019t explain on their own. It collects more than 300 metadata attributes of protocols and files, inspects sessions deeply, and profiles TLS traffic to help separate human from machine activity. It detects lateral movement, correlates alerts against MITRE ATT&CK, and applies new threat intelligence to stored history. Sensors cover internal as well as inbound and outbound traffic, with on-premises, VM, and cloud options.<\/p>\n

Fidelis Deception<\/a>\u00ae covers the places where installing software isn\u2019t possible. It places decoys that resemble real assets, so any interaction is suspicious, and it works without agents on endpoints. A Fidelis customer, a university children\u2019s hospital<\/a> with nearly 5,000 staff and volunteers, deployed it out of line and agentless, with no network performance impact, and it surfaced scanning from an associate organization and unauthorized tools. That example shows a detection use case, not a full zero trust program.<\/p>\n

For identity, Fidelis Active Directory Intercept<\/a> adds AD-aware detection, deception, and log monitoring to the directory service at the center of many environments.<\/p>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
Real-Time Insight, Real-Time Prevention with Fidelis Network<\/div>\n<\/div>\n<\/div>\n
\n
\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tBlock attacks before damage occurs<\/span><\/p>\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tPrevent lateral movement inside your network<\/span><\/p>\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tReduce false positives & alert fatigue<\/span><\/p><\/div>\n<\/div>\n

\n
\n
\n\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\tRead Guide<\/span>
\n\t\t\t\t\t<\/span>
\n\t\t\t\t\t<\/a>\n\t\t\t\t<\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n
\n
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n
\n

A Practical Way to Measure Progress<\/h2>\n<\/div>\n<\/div>\n
\n
\n

No single number proves a zero trust architecture is done. Useful indicators include:<\/p>\n<\/div>\n<\/div>\n

\n
\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tInventory: systems and devices with a known owner and communication profile, checked against observed traffic. HHS\u2019s proposal would require inventories and network maps reviewed at least every 12 months, but that remains proposed.<\/span><\/p>\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tPrivilege: administrative and vendor accounts reviewed, and how many were narrowed or removed.<\/span><\/p>\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tVisibility: whether the paths for the highest-risk workflows are monitored and understood.<\/span><\/p>\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tExcessive access: how much was found and how long closing it took.<\/span><\/p>\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tDetection coverage: which segments and system types sit inside monitoring and which don\u2019t.<\/span><\/p>\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tSegmentation validation: rules tested after each change, with clinical workflow checks recorded.<\/span><\/p>\n

\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>
\n\t\t\t\t\t\t\t\t\t\tResponse time: time to investigate relevant events, tracked as a trend, not a target.<\/span><\/p><\/div>\n<\/div>\n

\n
\n

Healthcare Zero Trust Starts Where the Risk Is Highest<\/h2>\n<\/div>\n<\/div>\n
\n
\n

Healthcare zero trust comes together through small, bounded changes: a vendor connection brought under control, a device network separated, a critical path made visible, a policy tested with the clinicians who rely on it. None of it requires replacing every legacy system first. To go further on how network detection and deception<\/a> can complement a healthcare zero trust strategy, especially when legacy systems and connected devices limit what teams can deploy directly, see our healthcare deception white paper.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n
\n

Frequently Asked Questions<\/h2>\n<\/div>\n<\/div>\n
\n
\n
\n
\n
\n

Can a hospital implement zero trust without replacing legacy systems?<\/h3>\n<\/div>\n
\n

Yes. NIST expects incremental adoption and hybrid operation, so controls move to the paths around systems that can\u2019t change.<\/p>\n<\/div><\/div>\n

\n
\n

Is zero trust required under HIPAA?<\/h3>\n<\/div>\n
\n

HHS recommends it as a voluntary strategy. The current Security Rule remains in effect, and the 2024 proposal hasn\u2019t been finalized. Confirm legal obligations with counsel.<\/p>\n<\/div><\/div>\n

\n
\n

Does network detection replace segmentation or access controls?<\/h3>\n<\/div>\n
\n

No. Detection shows actual behavior and tests whether controls work, but it doesn\u2019t enforce access.<\/p>\n<\/div><\/div>\n

\n
\n

What should teams do first?<\/h3>\n<\/div>\n
\n

Build a workflow-based inventory of high-impact systems, strengthen remote, administrative, and vendor access, and make critical communication paths visible before segmenting in stages.<\/p>\n<\/div><\/div>\n

\n
\n

Who should approve segmentation changes for medical devices?<\/h3>\n<\/div>\n
\n

Clinical engineering, IT security, and where relevant the device manufacturer, together, because some devices depend on their network connections.<\/p>\n<\/div><\/div>\n<\/div><\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n
\n

Citations:<\/p>\n<\/div>\n<\/div>\n

\n
\n\t\t\t\t\t\t\t\t\t^<\/a>https:\/\/nvlpubs.nist.gov\/nistpubs\/specialpublications\/NIST.SP.800-207.pdf<\/a>^<\/a>https:\/\/www.fda.gov\/media\/119933\/download<\/a>^<\/a>https:\/\/405d.hhs.gov\/Documents\/405d-hicp-highlight.pdf<\/a>^<\/a>https:\/\/hphcyber.hhs.gov\/documents\/cybersecurity-performance-goals.pdf<\/a>^<\/a>https:\/\/www.federalregister.gov\/documents\/2025\/01\/06\/2024-30983\/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information<\/a>^<\/a>https:\/\/www.cisa.gov\/resources-tools\/resources\/adapting-zero-trust-principles-operational-technology<\/a>^<\/a>https:\/\/csrc.nist.gov\/news\/2025\/implementing-a-zero-trust-architecture-sp-1800-35<\/a>\t\t\t\t\t\t\t\t<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

The post Building Zero Trust Across Healthcare\u2019s Legacy and Connected Environments<\/a> appeared first on Fidelis Security<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"

Key Takeaways Healthcare zero trust requires phased implementation that protects patient safety and clinical availability while reducing implicit trust. Legacy clinical systems can be protected through gateways and compensating controls when upgrades or agents are impractical. Strong identity controls, time-bound vendor access, and least privilege help reduce unauthorized access to critical systems. Healthcare network segmentation […]<\/p>\n","protected":false},"author":0,"featured_media":10135,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-10134","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/10134"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=10134"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/10134\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/10135"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=10134"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=10134"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=10134"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}