Zero Trust Implementation: Running the Migration, Not Describing It

What implementation actually changes

A perimeter model answers one question: is this request coming from inside? A zero trust model answers a different one, per request: should this identity, on this device, in this posture, at this time, from this location, get this access to this resource? The change is not the removal of a firewall - it is the insertion of a decision point into every access path, and the provision of enough context for that decision to be worth making.

That reframing has three consequences that shape the whole programme. First, the quality of the decision depends on the quality of the signals: identity is only meaningful if it is unique and strongly authenticated, device posture is only meaningful if the fleet is managed, and a policy evaluated against stale data is theatre. Second, availability becomes a security property, because a decision point in every path is also a failure point in every path - implement it badly and you have built a single device that can take the company offline. Third, the work is uneven: some applications are trivially proxied, some need rewriting, and a handful will keep a legacy exception for years, which means the programme is a portfolio of migrations rather than one cut-over.

NIST SP 800-207 (August 2020) describes the shape: a policy decision point that evaluates a request, and policy enforcement points placed in front of the resources, with the decision informed by identity, device, threat intelligence and enterprise policy. CISA's Zero Trust Maturity Model v2.0 (April 2023) organises the work into five pillars - identity, devices, networks, applications and workloads, data - with visibility and analytics, automation and orchestration, and governance as cross-cutting capabilities. Both are useful as vocabulary. Neither tells you what to do on Monday, which is what the rest of this guide is about.

The decision architecture: PDP, PEP and why the engine needs context

The architecture question that decides whether the programme works is where the decision is made and what it can see. A policy engine that only knows an IP address and a username is a firewall with better branding. A policy engine that knows the identity's authentication strength, the device's compliance state and last-known posture, the sensitivity of the resource, the session's risk and the time of day can enforce something worth enforcing.

Three practical design rules. Keep the decision engine highly available and deterministic - it should fail closed for high-sensitivity resources and fail open to a constrained path for low-sensitivity ones, and that asymmetry should be a written decision rather than a reflection of how the product ships. Keep policy expressed as code, versioned in a repository with review, so that a change can be diffed, rolled back and audited; policies that exist only in a vendor console are policies nobody can review. And keep the enforcement points close to the resources rather than to the users, because enforcement at the edge protects the network you have while enforcement at the resource protects the resource wherever it lives - including in a cloud account nobody told you about.

Then there is the honest operational question: what happens when the engine is unavailable? Every mature programme has an answer that involves a documented break-glass path, a separate credential store, physical or out-of-band verification, an alert that fires when the path is used, and a review afterwards. Programmes that skip this step discover the gap during their first outage, and the workaround improvised at that moment usually becomes permanent.

Phase 0: the user journeys that must keep working

Before any technology, write down the twenty or thirty journeys that the business runs on: the warehouse scanner that syncs overnight, the finance team's month-end upload, the contractor who connects from a personal laptop to review drawings, the support desk that needs to see a customer's screen, the build pipeline that pulls from a repository, the payroll batch that runs at 02:00. Each journey has an identity, a device, a protocol and a data sensitivity. That list is the migration plan's test suite, and every phase is judged by whether those journeys still work.

Two things fall out of doing this properly. You discover how many journeys depend on network position rather than on identity - the application that trusts anything arriving from a particular subnet, the database with an allow-list of office ranges, the internal tool with no authentication at all because it was never exposed. Those are the migration's real cost, and finding them in a spreadsheet is cheaper than finding them in a support queue at 09:00 on the Monday after a cut-over.

And you discover the exceptions that will never be migrated, which should be documented as exceptions with an owner and a compensating control rather than left to be rediscovered. A single-sign-on exception for a manufacturing system from 2009 is not a failure of the programme; an undocumented one is.

Phase 1: identity is the control plane

Every zero trust programme begins with identity, and the reason is not fashion: if the identity is ambiguous, every downstream decision inherits the ambiguity. The phase has a defined finish line - one authoritative directory, one strong authentication story, one lifecycle process - and it is worth doing thoroughly before moving on.

Consolidate to a single identity provider for workforce access, with cloud and on-premises applications federated to it, so that authentication events land in one place and revocation is one action. Then strengthen the factor: phishing-resistant authentication for administrators, for anyone who can approve payments or export data, and eventually for everyone, using passkeys or security keys rather than push approvals. Then make authorisation reflect roles rather than habit - group membership derived from HR attributes, privileged roles granted just-in-time with an approval and an audit trail, and standing administrative rights removed wherever the platform supports it.

The lifecycle process is the part that quietly determines the security outcome. Joiners, movers and leavers driven from the HR system; a monthly reconciliation listing accounts with no matching employee, dormant accounts, and service accounts with interactive login enabled; access reviews for the roles that matter, with the reviewer being the business owner rather than the security team. NIS2 Article 21(2)(i) asks for access control policies and multi-factor authentication assessed against risk, and this is where the evidence for that answer is produced.

Phase 2: device trust as a signal, not a gate

The device is the second input to the decision, and the most commonly over-simplified. "Managed device" is not a posture; a laptop enrolled six months ago that has not checked in since is managed and unknown. What the policy engine needs is a current, attested statement about the device: is it enrolled, is disk encryption on, is the operating system patched to the required baseline, is the endpoint agent healthy, is it jailbroken or rooted, has it been seen in the last day.

Build that signal from the endpoint management platform and the endpoint detection agent, expose it to the policy engine, and then use it to vary access rather than to deny it outright. A compliant managed laptop gets the application; an unmanaged personal device gets a browser-isolated session with no download and no clipboard; a device that fails a critical check gets a remediation page. That graduated response is what keeps the programme usable - the alternative, a binary allow-or-deny, produces a support queue full of people whose only problem is a pending reboot.

Two details matter more than they look. Device identity should be cryptographic where possible - a certificate issued at enrolment - because a device name in a user agent string is a claim, not a fact. And the BYOD path needs to be a designed product rather than an exception: contractors, subsidiaries and personal phones are a permanent part of the estate, and a programme that pretends otherwise will find them connecting through a shadow path within a month.

Phase 3: application access without a VPN

The VPN is where most programmes start because it is the most visible piece of implicit trust: one connection, and then the network decides for you. Replacing it is a migration in three tranches, and doing it in the right order avoids the classic outcome where the VPN stays, the new gateway runs beside it, and the estate ends up with two ways in and no policy that covers both.

The first tranche is the easy majority: web applications behind identity-aware proxies, with per-application policy rather than per-network policy. The migration is mechanical for single-sign-on capable apps, and the win is immediate because each application now has an owner, an access list and a log. The second tranche is thick-client and protocol traffic - RDP, SSH, database clients, file shares - which needs a client-based proxy or a per-application tunnel rather than a network tunnel, so that the user reaches one service rather than a subnet. The third tranche is the difficult residue: applications that cannot be proxied at all, because their protocol is proprietary, or because they hard-code server addresses, or because the vendor has abandoned them. Those become documented exceptions with compensating controls, and the compensating control that usually works is placing them behind a jump host that itself is zero-trust protected.

Two migration mechanics make or break this phase. Publish the policy before enforcing it - run in log-only mode for a fortnight, review the denials, and fix the policy before anyone is blocked - because the list of legitimate-but-unexpected traffic always includes something the business needs. And measure the user experience while you migrate: connection time, number of authentication prompts, and the volume of tickets tagged as access failures. A programme that improves security and destroys the working day will be reversed by the first executive who is inconvenienced.

Phase 4: segmentation where the flat network used to be

East-west traffic is where perimeter thinking fails hardest, because a flat internal network means any compromised workstation can reach the database, the domain controller and the backup server. Segmentation is the answer, and the version that works in practice is not the one drawn in the architecture review.

Start from the data and the dependency map rather than from the network diagram, because the diagram is usually wrong and the dependency map is usually missing. Enumerate which services talk to which, over which ports, with which credentials, using flow data from the existing network rather than from interviews. Then define zones around the applications that matter - the finance system, the domain controllers, the backup infrastructure, the manufacturing control network - and enforce between zones with policy applied at the workload rather than at the switch where possible, because host-based enforcement survives migrations to cloud and does not require a network change window.

The failure modes are consistent. Tag drift: a workload's label stops reflecting what it is, and the policy silently protects the wrong thing. Policy sprawl: hundreds of rules accumulate as each application gets an exception, and nobody can say what the effective policy is. And the untouchable application: the one nobody understands, with a hard-coded IP, which becomes the hole through which a segmentation programme is quietly abandoned. The mitigation for all three is the same - treat the policy as code, review it quarterly, and require a named owner for every exception with an expiry date.

Phase 5: the non-human half of the estate

Most zero trust programmes are designed as if the only principals were people. In a typical estate the non-human identities - service accounts, API keys, CI/CD tokens, cloud roles, application certificates - outnumber the humans several times over, and they are usually long-lived, broadly scoped and rarely rotated. An attacker who finds one does not need to phish anybody.

The implementation pattern is short-lived, scoped, cryptographically bound identity for workloads. Workload identity frameworks - SPIFFE and SPIRE are the reference implementations, with X.509 SVIDs issued to a workload and rotated automatically - replace static secrets for service-to-service authentication. Cloud workload federation replaces long-lived access keys with tokens minted for a specific workload, a specific audience and a short lifetime. Mutual TLS between services replaces the assumption that anything inside the network is a trusted caller. Secrets management with automatic rotation and audit replaces the configuration file with a password in it.

The migration is best done as an inventory first: every credential that can authenticate, where it is stored, what it can reach, when it was last rotated, and who owns it. That list is usually longer than expected and contains several entries whose owner has left. Then retire in order of blast radius - production database credentials, cloud administrator keys, CI/CD tokens with deploy rights - and replace each with a short-lived identity rather than a better-kept secret.

Phase 6: data controls as the last line, not the first

Data is where the other phases are cashed in, and it is also where programmes most often start - with a classification exercise, a labelling policy and a data loss prevention product - which is the wrong order. Classification without enforcement produces a policy that says some data is confidential while the collaboration platform offers an anonymous sharing link to every file in it. Enforced sharing defaults produce a measurable reduction in exposure on the day they are switched on. Do the enforced part first and the classification becomes useful rather than aspirational.

Three tiers is enough for almost every organisation: public, internal, and restricted. Five tiers guarantee that nobody labels correctly, because the difference between confidential and highly confidential is a judgement call that people make differently on a Tuesday. The tiers should be carried by the platform rather than by a separate tool - sensitivity labels in Microsoft 365, Drive labels, object tags in object storage - so that the label controls encryption, external sharing, download rights and retention instead of merely describing them. The test of a labelling scheme is simple: name a document type, and an ordinary employee should be able to say which tier it belongs to without asking. If they cannot, the scheme has too many tiers, too vague a definition, or both.

The controls that actually move the number are unglamorous. External sharing off by default at the tenant level, with named exceptions; links that expire and that cannot be made anonymous; encryption with keys you control for the restricted tier, and a written answer about what happens to those keys if the provider's region changes; versioning and deletion protection so that ransomware has to work harder than a single password; and browser isolation for unmanaged devices, so a contractor reading a restricted document does it through a session that cannot download or copy to the clipboard. Data loss prevention belongs in that list as a triage instrument, not as a boundary: tuned in audit mode for a month first, measured on false positives per week, and aimed at the two or three patterns that matter - personal email addresses, cloud storage destinations, payment card data - because a DLP rule set with two hundred patterns is a rule set that gets muted.

Honest limits are worth stating in the policy itself. DLP does not stop a screenshot, a photograph of a screen, a determined user with a personal account, or an insider who exports gradually. What catches those is egress filtering and anomaly detection on volume - the account that downloads four hundred files in an hour when its baseline is eleven - plus rights management that keeps the document encrypted wherever it goes. GDPR Article 32(1)(a) and (b) ask for confidentiality, integrity and availability through appropriate technical measures; ISO/IEC 27001:2022 puts classification in A.5.12, labelling in A.5.13, data leakage prevention in A.8.12 and cryptography in A.8.24; NIS2 Article 21(2)(h) asks for a cryptography policy where appropriate. None of those require a specific product. All of them require that the decision about who may read what is made consistently and can be shown.

One architectural point ties this phase back to the policy engine. Data sensitivity has to be an attribute the decision point can evaluate - this resource is restricted, this one is internal - or the engine will keep making decisions from network position and stating them in the vocabulary of data protection. Where labels reach the policy engine, a request for a restricted document from an unmanaged device can be answered with a browser-isolated session rather than with a document that is either fully available or fully blocked. That is the difference between a control and a restriction.

Phase 7: telemetry, detection and the policy denial as a signal

The decision point produces something the perimeter never did: a continuous, structured record of intent. Every denial is a request that a real identity made in good faith or otherwise, against a real resource, that policy refused. Every allow carries the reason it was allowed. That stream is the most valuable detection asset a zero trust programme generates, and the most commonly wasted: programmes route the gateway's logs to a syslog server nobody queries and continue alerting only on endpoint malware.

Log the decision, not just the outcome. The useful record is identity, device identifier and posture state, resource, policy identifier, verdict, the condition that decided it, source network, and time - with the correlation identifier that ties it to the identity provider's authentication event and to the endpoint agent's record of the same session. When an incident happens, that chain is what lets an analyst answer the only question that matters in the first hour: which sessions were established with this credential, and are any of them still open. Retention is a design decision, not a storage accident: ninety days searchable for decisions, twelve months for identity and administrative audit events, and a documented answer for anything legal or regulatory that needs longer.

Four signals are worth building first, because they are cheap and they catch the cases that matter. A denial spike for one application after a policy change is almost always a broken policy rather than an attack, and catching it within minutes turns an outage into a change. Repeated denials across many resources by one identity look like enumeration or a misconfigured client, and both deserve attention. Break-glass credential use, or a policy change made by a human outside the change window, is the highest-value alert in the whole estate because it is rare and almost always significant. And the sequence that describes a real takeover - a factor reset, then a session from a new network, then a posture check that no longer passes - is a query against data you already have, not a new product.

Measure the pipeline, because it fails quietly. The number that matters is not events ingested but the time from an event happening to it being queryable, and the percentage of decision points that are actually shipping logs. A gateway added by a team in a subsidiary and never onboarded to the log pipeline is a hole that no dashboard will show unless you compare the inventory of enforcement points against the inventory of log sources. Buffer locally at the enforcement point so that a log pipeline outage does not become an access outage, and treat the buffer's depth as a capacity figure you can quote.

Detection engineering then follows the same discipline as the rest of the programme: take the attack paths that matter for your business, express each as a behaviour that would be visible in the telemetry you hold, write the detection, test it against a simulated technique, and give it an owner and a review date. Coverage measured as behaviours with a tested detection is a number a board can act on; coverage measured as tools deployed is a number that grows while the estate gets breached. NIS2 Article 21(2)(f) asks for procedures to assess whether the measures you took are effective, and this is where that assessment is done - not in a document, in a detection library with dates on it.

Migration tactics: cohorts, break-glass and rollback

A zero trust migration is a change programme with a security outcome, and the tactics that decide whether it lands are the ordinary ones: who goes first, what happens when it breaks, and how the organisation is told. Programmes that skip these tactics do not fail on architecture. They fail in the third week, when the helpdesk has forty tickets and the executive who was asked to log in twice asks for the old system to be switched back on.

Choose the first cohort for tolerance, not for importance. The identity and infrastructure team itself, then a group of engineers who understand what a policy denial means and will report it precisely, then an office with a single location and stable connectivity. Finance, sales and anything with a month-end or a quarter-end deadline go last, and never in the same week as a release. Twenty to fifty people for a fortnight is enough to find the policy errors that matter; a pilot of five users finds nothing because five users do not exercise the long tail of access patterns. Keep a named engineer on rotation for the cohort's tickets and count them daily - the ticket rate per hundred users is the programme's real velocity number.

Enforce in a ladder, never in a jump. Log-only for a fortnight, with a weekly review of the denials that would have blocked someone; warn for a week, where the session continues but the user is told what would have happened and why; then enforce for the cohort. The warn stage is what makes the difference between a rollout that people accept and one they route around, because it converts an invisible policy into an explained one. Publish a self-service page that answers the three questions a blocked user actually has - what was blocked, how to fix it, who to contact - and give the helpdesk a script and a dashboard before the first enforcement day, not afterwards.

Break-glass access is not an admission of weakness; it is the control that stops an outage from reversing the programme. Two accounts per critical platform, credentials held outside the identity provider that the programme depends on - a safe, or a separate vault with a different administrator - excluded from the policy engine by construction, with use alerting to a channel that a human reads. Test the path quarterly and rotate the credentials after every use. The failure mode to avoid is the break-glass account that shares a dependency with the thing it is meant to bypass: a recovery credential stored in the same tenant whose misconfiguration is why you need it.

Rollback has to be provisioned, not imagined. For each tranche, keep the previous access path in place but disabled at the network layer, with a written switch-back procedure, a named owner and a time limit after which the old path is deleted. A rollback that takes four hours to reconstruct is not a rollback, it is an incident. Decide in advance which tranches are not reversible - usually the ones where a VPN concentrator was decommissioned - and make the go/no-go decision for those explicit, with the application owners in the room.

Exceptions deserve their own process because they will be the largest thing in the programme. Every exception gets a requesting owner, a business justification, a compensating control and an expiry date, reviewed monthly. An exception register with forty entries and no expiries is a description of a programme that has stopped; a register with eighteen entries, four expiring this quarter and a named executive sponsor for each is a programme with a trajectory. The same discipline applies to third parties: contractor access with a sponsor, an end date set at creation, and automatic expiry when the contract does.

Failure modes that make the programme cosmetic

Most of the ways a zero trust programme fails are predictable, and none of them is technical. The following list is drawn from the pattern that repeats across mid-market migrations, and each entry has a cheap detector.

The decision point that is not in the path. The new gateway is deployed, the pilot loves it, and the VPN is still running for everyone else, so the estate has two ways in and policy covers one of them. Detector: compare the number of sessions on the legacy path against the number on the new one weekly; a legacy path with traffic six months after cut-over is the programme's biggest hole.

Identity consolidation skipped. The policy engine evaluates an identity that two directories disagree about, so the same person has two accounts with different privileges and revocation is done twice or not at all. Detector: the monthly reconciliation that lists accounts without a matching employee.

Log-only for ever. Nobody ever turns enforcement on because every denial is treated as a business risk, and the programme reports success with a denial rate of zero. Detector: if the enforced deny count for the quarter is zero, the policy is not enforcing anything.

An exception list that eats the estate. Each difficult application becomes an exception with no expiry, and within a year the exceptions carry more traffic than the policy does. Detector: percentage of flows covered by enforced policy rather than by exception, reported monthly.

Device posture as a checkbox. Managed is treated as healthy, an agent that has not reported for ninety days still counts as compliant, and a laptop with disk encryption disabled passes because the enrolment record says so. Detector: the age of the last posture report for each device in the allow set.

The non-human estate left out. Service accounts with interactive login enabled, API keys older than the staff who created them, CI tokens with deploy rights that never rotate. Detector: the credential inventory, sorted by age and blast radius - if it does not exist, that is the finding.

The pilot that never scales. Thirty users on a designed path is not evidence for three thousand, because the long tail of applications and the helpdesk load only appear at scale. Detector: onboarding rate per month, and whether it is rising or flat.

Run as a network project. The network team owns the programme, but the work that remains after the gateway is deployed is application authentication, which belongs to application owners who were never in the room. Detector: whether the application owners can name the policy that covers their application.

Metrics that measure deployment. Agents installed, applications onboarded, users migrated - all of which rise while standing privilege, lateral movement and credential age stay exactly where they were. Detector: whether any reported metric would get worse if the programme were failing.

No break-glass, no rollback, no plan for the first outage. The first serious incident produces an improvised workaround that becomes permanent, and the programme's own availability risk becomes the reason it is scaled back. Detector: the date the break-glass path was last tested.

Metrics and a maturity ladder that means something

CISA's Zero Trust Maturity Model v2.0 gives the programme a shared vocabulary: identity, devices, networks, applications and workloads, and data as the five pillars, with visibility and analytics, automation and orchestration, and governance cutting across all of them, and four stages - traditional, initial, advanced, optimal - for each. Use it to describe where you are and to structure a plan; do not use the stage label as a target, because optimal on every pillar is not a realistic goal for a mid-market organisation, and pretending otherwise converts a useful model into a grading exercise nobody wants to sit.

What a board actually needs is a short list of numbers that move only when the security outcome moves. Twelve is about the limit before the page stops being read: the share of the workforce authenticating with a phishing-resistant factor, and separately the share of privileged accounts; the number of standing administrative roles that could be removed and have not been; applications behind an enforcing decision point as a proportion of applications that matter; the share of east-west traffic covered by a deny-by-default policy rather than an exception; median time from a compromised credential being identified to its sessions being revoked; the age of the oldest credential in the non-human inventory; the count of break-glass uses this quarter; open exceptions and how many are past their expiry; the number of enforcement points that are not shipping logs; and the median time to remediate a failed posture check. Two of those are not security metrics in the conventional sense - the denial rate per application and the policy change lead time - but they are the two that tell you whether the programme is operating or frozen.

Report trend against target with an owner per line, and attach a decision to every gap rather than a concern. A line that reads sixty-eight per cent of privileged accounts on phishing-resistant factors, target ninety per cent by end of quarter, owner infrastructure lead, blocked by two manufacturing systems awaiting vendor support, is worth more than a maturity score, because a reader can act on it. The same list, tracked quarterly, also answers the regulatory question about effectiveness without a separate evidence exercise: NIS2 Article 21(2)(f) wants procedures for assessing whether measures work, and a trend line with an owner is that procedure.

The regulatory reading: NIS2, DORA and the framework

Zero trust is not named in European law, and it does not need to be: the obligations are written in terms of access control, authentication, segregation, monitoring and continuity, which is what the phases above produce. NIS2 - Directive (EU) 2022/2555 - requires access control policies and asset management in Article 21(2)(i) and multi-factor or continuous authentication together with secured communications in Article 21(2)(j), supply chain security in Article 21(2)(d), and the management body's approval and oversight in Article 20. The reporting clocks in Article 23 - an early warning within 24 hours, a notification within 72 hours, a final report within one month - are the reason the revocation time metric matters: an entity that cannot say which sessions used a stolen credential cannot write a credible 24-hour warning.

DORA - Regulation (EU) 2022/2554, applicable since 17 January 2025 - applies directly to financial entities and reaches their ICT providers through contract. Article 9 requires protection and prevention measures with identity and access management inside the ICT risk-management framework; Article 10 requires detection of anomalous activity, which is the telemetry phase; Article 11 requires response and recovery, which is where the break-glass and rollback tactics belong; and the register of information on third-party arrangements means the segmentation work has to extend to suppliers rather than stop at the perimeter. Entities in scope of both regimes get one set of controls and two sets of evidence, and the evidence is cheaper to produce when it is a by-product of operating the programme.

For an audit mapping, ISO/IEC 27001:2022 Annex A covers the same ground: A.5.15 access control, A.5.18 access rights, A.8.2 privileged access rights, A.8.5 secure authentication, A.8.20 networks security, A.8.22 segregation of networks, A.8.16 monitoring activities, A.8.12 data leakage prevention and A.8.24 use of cryptography. The point of mapping is not the certificate. It is that an auditor's question - show me how access to this system is authorised and reviewed - is answered by a policy identifier in a decision log rather than by a description of intent.

One caution about regulators and vendors alike: a maturity assessment sold by the company that sells the platform measures the platform. If a third party is going to score the programme, ask for the scoring to be against outcomes you can verify - enforced denials, revoked sessions, retired credentials, tested restores - and for the evidence to stay in your repository when the engagement ends.

Conclusion: the sequence, and what to do in the first ninety days

The order that works is the order in this guide: know the journeys, fix identity, make device posture real, move application access off the network, segment what is left, bring the non-human estate in, then let data sensitivity and telemetry do the work that only they can do. Each phase has a finish line that can be described in one sentence, and each is worth finishing before the next begins - not because the model is rigid, but because every later phase assumes the earlier one produced a trustworthy signal.

The first ninety days, concretely: consolidate to one identity provider for workforce access and count the exceptions; put phishing-resistant factors on every administrative account; write the journey list and mark which journeys depend on network position; deploy one application behind an identity-aware proxy in log-only mode with a named owner; inventory every credential that can authenticate and sort it by age and blast radius; test the break-glass path; and put the twelve metrics on one page with a baseline, even if the baseline is bad. None of that requires a platform purchase decision, and all of it makes the purchase decision easier.

What to expect: the programme will feel slow for two quarters and then accelerate, because the early work is discovery and the later work reuses what discovery produced. What to refuse: a cut-over date set before the journey list exists, an exception without an expiry, a pilot with no onboarding rate, and a dashboard that would look identical if the programme were failing.

Where this connects to the rest of our work: the concept and the seven tenets are in our zero trust overview, which stays the short explanation; the programme-level governance around this migration is in the enterprise security programme guide; the remote-access layer is in the enterprise VPN and network access guide; and the response side, including how a stolen session is contained, is in the incident response plan guide. The Italian partner to this guide is at Zero Trust: guida all'implementazione.