Managed servicesIdentity & access
Verify every access — before mail, files, or plant systems open
Identity and device health checks on every login — so being on the office Wi-Fi or connected to a VPN is not treated as proof someone should reach client work
Perimeter firewalls and VPNs were built for a world where work happened in one building on company-owned PCs. Today, cloud mail, hybrid file stores, and mobile staff mean “inside the network” is not a reliable trust signal. Zero Trust access treats every request as untrusted until identity, device health, and context pass policy — then grants the least privilege needed for that session.
Technology partners
Zero Trust is not “no firewall” — and a VPN checkbox is not Zero Trust
Firewalls still matter — they filter traffic at the edge. Zero Trust answers a different question: “Should this person, on this device, from this location, reach this application right now?” Legacy VPNs often grant broad network access once credentials match. Zero Trust Network Access (ZTNA) connects users to specific apps with continuous checks — not an all-access tunnel into the LAN.
You will see terms like policy decision engine (PDE), just-in-time access (JIT), and just-enough-administration (JEA). Plain language: a PDE is where login rules run — MFA, device health, risk score. JIT/JEA mean temporary, narrow permissions instead of standing admin. We define each once, then design around outcomes you can explain to partners.
What is Zero Trust access?
Zero Trust is a security framework: authenticate and authorize every user and device, then keep validating through the session — inside or outside the office. The motto “never trust, always verify” means location alone does not grant access. Cloud identity (Microsoft Entra ID / Azure AD, Okta, or Google Workspace) plus conditional access policies is how most firms implement it without replacing every system at once.
How one access request is decided
Incoming request (identity + device + location)
│
▼
Policy decision engine (MFA · device health · risk)
│
┌────┴────┐
▼ ▼
Deny / Allow with
Challenge least privilegeEvery login is evaluated the same way — remote or in the office. The policy engine returns allow, challenge, or deny before the session reaches sensitive apps.
What happens on each access attempt
Four decision points — flip a card for the plain-English detail
Hover or tap each step to see what the policy engine evaluates before mail, files, or a line-of-business app opens — the same path for staff, partners, and vendors.
Incoming request
Someone tries to open mail, a file share, or a plant system. The request carries identity (who), device (what machine), and context (where, when, how risky).
Policy decision engine
Rules run in one place: require MFA, check device compliance, compare location to policy, and score risk — before any app opens.
Deny or challenge
Failed checks block the session or step up verification — extra MFA, device registration, or admin approval — instead of silently granting network-wide access.
Allow with least privilege
Approved sessions reach only the apps and data that role needs — not every server on the LAN. Permissions can expire (JIT) and shrink standing admin (JEA).
Three pillars of Zero Trust access
Explicit verification, least privilege, and assume breach — as operational controls
Manage IT NY maps Zero Trust from framework language to policies your staff can follow and partners can ask about — without a rip-and-replace weekend.
Explicit verification
Stops this failure mode: “They were on VPN, so we assumed it was fine”
Every access request is authenticated and authorized with MFA and device checks — in the office, at home, or on a vendor laptop. Location is context, not proof.
Least privilege
Stops this failure mode: one stolen password unlocks the whole network
Users, admins, and vendors receive only the apps and rights they need — often just-in-time (JIT) with expiry. Standing domain admin on every laptop is the exception, not the default.
Assume breach
Stops this failure mode: silent lateral movement after one foothold
Segment apps and data, encrypt sessions, and monitor sign-in patterns so a single compromise does not become firm-wide encryption. Zero Trust pairs with EDR and backups — it does not replace them.
Verify every time
Session trust decays
A login at 9 AM does not guarantee the same person holds the session at 2 PM. Continuous assessment re-checks risk when context changes — new device, new country, or unusual data access.
Least privilege
App-level, not network-wide
ZTNA publishes specific applications — mail, ERP, a file share — instead of placing the user on the internal LAN. Smaller blast radius when credentials leak.
Assume breach
Design for the foothold
Segmentation, logging, and encryption assume someone may already be inside. The architecture limits how far they can move while detection and response investigate.
ZTNA
Zero Trust Network Access
The modern replacement for “VPN into everything.” Users connect to apps through an identity-aware broker — not a flat tunnel that trusts the whole network.
What good looks like
A short buyer checklist before you trust the program — not a vendor SKU list, a readiness scan.
MFA on critical apps?
Mail, file shares, VPN/ZTNA, and admin portals require phishing-resistant or context-aware MFA — not optional toggles only partners use.
Device health checks?
Managed devices prove patch level and encryption before they reach client data. Personal laptops follow a documented BYOD path — or stay blocked.
App-level access, not LAN-wide VPN?
Remote staff reach specific SaaS and published apps — not every server subnet because the VPN connected.
Vendor access expires?
Third-party logins are time-bound, logged, and revocable the same day — not shared passwords that live forever.
BYOD rules documented?
Personal phone and laptop policy is written, enforced in identity policies, and explainable to clients — not “we think IT said no.”
ZTNA vs legacy VPN — what changes for staff and auditors
Select a dimension to compare how perimeter VPN trust differs from app-level Zero Trust access — in language ops leaders and compliance reviewers can follow.
Implicit LAN trust vs verify every session
Legacy VPN: once connected, the user is often treated as “inside” — with broad reach to internal subnets. ZTNA: each app session is verified independently. Being connected does not mean every server is reachable.
Assess access postureFlat network vs segmented app access
VPN footholds frequently enable lateral movement — scan and hop across the LAN. ZTNA publishes specific applications with identity-aware paths, shrinking how far stolen credentials can travel.
Pair with EDR / MDRPassword at the tunnel vs MFA on every app
Many VPNs still rely on a single password (sometimes without MFA) at connect time. Zero Trust stacks MFA, conditional access, and risk signals on each resource — including step-up when travel or device posture looks wrong.
Email & identity protectionAny device on VPN vs compliant device only
Personal laptops often ride the same VPN as managed PCs. Zero Trust checks patch level, encryption, and management status before release — BYOD is a policy choice, not an accident.
Endpoint lockdownTunnel logs vs per-app session evidence
VPN logs show connect/disconnect — not which application was opened or which file was touched. ZTNA and conditional access produce per-app, per-user session detail partners and assessors increasingly ask for.
Review logging gaps1 / 5
Four-step verification workflow
How a typical sign-in is evaluated before sensitive apps open — the teaching sequence you can walk through with leadership. Timing is illustrative; real prompts depend on identity provider, device fleet, and policy strictness.
The user presents credentials; the identity provider requires MFA — app prompt, hardware key, or phishing-resistant method. Shared passwords and legacy SMS-only flows are phased out for roles that touch client data.
How Zero Trust access maps to your industry
CMMC access controls, ABA competence expectations, and IRS/FTC safeguards all ask whether only the right people reach sensitive systems — with evidence. Here is how Manage IT NY translates Zero Trust into language each vertical already uses.
Defense industrial base — CMMC & NIST AC controls
NIST SP 800-171 access control (AC) family expects least privilege, session lock, and remote access monitoring on systems that handle CUI. Zero Trust conditional access, MFA, and ZTNA for published apps support AC controls assessors map during CMMC reviews — alongside segmentation and logging, not instead of them.
CMMC enclave pathLaw firms — ABA Model Rules 1.1 & 1.6
Competence and confidentiality expect firms to understand technology risks — including who can reach matter files from home or a vendor portal. MFA, device checks, and app-level access help demonstrate reasonable efforts when partners explain safeguards to clients or malpractice carriers.
Law firm cybersecurityAccounting — FTC Safeguards & IRS Pub 4557
Written information security plans and Safeguards Rule programs expect access controls on systems that store taxpayer PII — including remote access during filing season. Documented MFA, vendor expiry, and session logging support the “who reached what” questions IRS and FTC frameworks imply.
Accounting firm cybersecurityManufacturing & hybrid plant access
Office staff, plant supervisors, and vendors often need different paths — ERP and mail without flat VPN into production networks. App-level ZTNA and segmented conditional access keep remote support scoped while EDR watches endpoints that bridge office and operations.
Manufacturing cybersecurityFrequently asked questions
Straight answers on firewalls vs Zero Trust, employee friction, BYOD, and how to migrate off a flat VPN without breaking filing season.
No. Firewalls filter traffic at the perimeter and between segments. Zero Trust governs who may open which application after identity and device checks pass. You still want both — plus EDR and backups — because they stop different failure modes.
Well-tuned policies add seconds — an MFA prompt or device check — not minutes per task. Modern single sign-on means one verified login reaches many apps. The friction you feel on day one is usually misconfigured exceptions and legacy apps that bypass SSO — we fix those in rollout, not by weakening MFA on client data.
BYOD is a policy choice, not a technical mystery. Common paths: register personal phones with app protection policies (mail and files containerized), block unmanaged laptops from sensitive apps, or provide managed devices for roles that touch PII. The rules should be written, enforced in conditional access, and explainable to clients — not different for every partner.
Yes — most firms transition in phases. Start with MFA and conditional access on cloud mail and files, publish critical apps through ZTNA, and narrow the legacy VPN to what still requires it. The goal is shrinking flat network access over quarters, not a risky same-weekend cutover.