# Zero trust, identity and segmentation (FAQ)

> 45 questions on Zero trust, identity and segmentation, in plain language: what to check, what NetSenX shows and what a sensor cannot see.

Source page: https://netsenx.com/en/faq/zero-trust

## Is zero trust realistic for a small business?

As a direction, yes; as a product you buy, no. Zero trust means not trusting a connection just because it comes from inside the network: every user and device proves who it is, and each gets access only to what it needs, checked again and again. A small company can go far with a few steps: multi-factor authentication on every account that faces the internet, separate networks for guests, IoT devices and servers, admin rights only where needed and through separate admin accounts, and a VPN or gateway that reaches only the systems each group uses. Do them in that order; each one is useful on its own. Network monitoring checks the result: NetSenX shows which hosts actually talk to which on monitored segments, on every plan, so a path that should not exist becomes visible.

https://netsenx.com/en/faq/is-zero-trust-realistic-for-a-small-business

## How do we check that network segmentation actually works?

Test it from both sides, then watch real traffic. From a host that should not get in, try to reach the protected segment with a simple connection test, and from inside the protected segment, check what it can reach outwards. Review the firewall rules between segments for broad allow rules, old exceptions and rules nobody can explain. Then watch, because rules drift: every change ticket, new application and supplier visit can add an exception, and the connections that actually cross a boundary are the real proof. Repeat the test after network changes and at least once a year. NetSenX shows host-to-host communication on monitored segments on its network map and flags new sessions that do not match a host's normal as lateral movement, on every plan, so an unexpected path between segments is visible the first time it is used. A path that exists but is never used is invisible to any passive sensor.

https://netsenx.com/en/faq/how-to-check-that-network-segmentation-works

## What does "assume breach" mean in practice?

It means planning as if an attacker is already inside, instead of relying only on keeping them out. The reason is practical: phishing, stolen passwords and supplier access mean the perimeter will be crossed sooner or later, so the questions become how far an intruder gets and how quickly you notice. In practice: limit what each account and host can reach, separate admin accounts from everyday ones, keep logs and network records long enough to investigate, keep offline backups, watch for movement inside the network, and rehearse what you will do when an alert comes, including who decides to disconnect a machine. Detection inside the network is part of this: NetSenX watches host-to-host traffic for scanning, lateral movement and beaconing, on every plan, so the steps an intruder takes after getting in become visible.

https://netsenx.com/en/faq/what-does-assume-breach-mean

## Can network access control (NAC) replace network monitoring?

No, they do different jobs. Network access control (NAC) decides which devices may join the network and which segment they land in, often using 802.1X, device certificates or a check of the device's health. It does not watch what an admitted device does afterwards, and most intrusions use devices and accounts that were let in legitimately: a phished laptop, a supplier's account, a printer with old firmware. Use both if you can: NAC to keep unknown devices out and put known ones in the right place, monitoring to see when a known device starts behaving like an intruder. For a small company, NAC can start simply, with port security on switches and certificate-based Wi-Fi. NetSenX covers the monitoring part: it flags scanning, lateral movement and beaconing from admitted devices on every plan, and its network map shows the devices seen on monitored segments.

https://netsenx.com/en/faq/can-network-access-control-replace-monitoring

## Does a VPN contradict zero trust?

A classic VPN does in one way: once connected, the user's device is usually inside the network with wide access, which is the trusted-because-inside model that zero trust moves away from. That does not mean the VPN must go tomorrow. You can bring it much closer to zero trust: require multi-factor authentication, give each group access only to the systems it needs, check that the device is a managed, updated company laptop before it connects, and log every session. Zero-trust network access (ZTNA) products take the next step and connect a user to one application at a time instead of to the network. Either way, assume that a VPN session can be abused and watch what it does. With a sensor on a SPAN or TAP port behind the VPN gateway, NetSenX flags scanning, lateral movement and beaconing from VPN users' devices, on every plan.

https://netsenx.com/en/faq/does-a-vpn-contradict-zero-trust

## What is zero-trust network access (ZTNA)?

ZTNA is a way of giving remote users access to individual applications instead of to the whole network. The user signs in through an identity provider, the service checks the user, the device and often its location and health, and then opens a connection to that one application only; the rest of the network stays invisible to the user. Many products deliver it as a cloud service with a small connector inside your network, so nothing needs to listen on the internet. For a small company it can replace a VPN for web applications and remote desktop, and it makes it easier to give a supplier access to one system without giving them the network. It does not remove the need to watch the inside: a compromised application server can still reach its neighbours. NetSenX does not provide ZTNA; it flags lateral movement and scanning from hosts on monitored segments, on every plan.

https://netsenx.com/en/faq/what-is-zero-trust-network-access-ztna

## Is a firewall still needed if we have zero trust or SASE?

Yes, in most offices. Secure access service edge (SASE) moves web filtering, secure remote access and some firewall functions into a cloud service, and zero trust changes how access is granted, but you still need something that blocks unsolicited connections from the internet into the office, separates network segments from each other and controls what servers and devices that never run the SASE client may reach. Printers, cameras, machines and many servers run no agent and are protected only by the network around them. So the firewall's role shrinks rather than disappears: inbound protection, segmentation and outbound rules for unmanaged devices. Keep its rules short and reviewed. NetSenX does not replace a firewall or a SASE service and blocks nothing. It watches the traffic that crosses monitored segments and flags scanning, lateral movement, beaconing and unusual outbound volume, on every plan, which tells you when either layer is being bypassed.

https://netsenx.com/en/faq/is-a-firewall-still-needed-with-zero-trust-or-sase

## How do segmentation and least privilege limit lateral movement?

They shrink what an intruder can reach from the first device they take over. Lateral movement means hopping from that device to others, usually with remote desktop, file shares or admin tools and with passwords gathered on the way. Segmentation puts firewalls or access rules between groups of systems, so a compromised office laptop cannot open a session to the database server or the backup system at all. Least privilege makes sure that the accounts found on that laptop cannot log in to servers either, because ordinary users are not local administrators everywhere and admin accounts are not used for e-mail. Allow-listing which hosts may use admin protocols closes the gap further. None of this is perfect, which is why it pairs with detection. NetSenX flags new host-to-host sessions over admin protocols that do not match a host's normal as lateral movement, on every plan, and from the Pro plan correlates them across hosts into one story.

https://netsenx.com/en/faq/how-does-segmentation-limit-lateral-movement

## Where do I start segmenting a flat office network?

Start with the systems whose loss would hurt most and the devices you trust least. A practical order for a small company: put guests and personal devices on their own network with internet access only; move printers, cameras, screens and other IoT devices into a device network that cannot start connections to PCs; put servers, especially backups, file servers and the domain controller, in a server network that PCs can reach only on the ports they need; and give administration its own path. Each step is useful alone, and most managed switches and firewalls can do it with VLANs and rules. Before you write rules, look at who actually talks to whom, so that you do not break a forgotten dependency, such as a scanner that saves to a file share. The NetSenX network map shows the hosts on monitored segments and who talks to whom, on every plan, which gives you that starting picture and then shows whether the new boundaries hold.

https://netsenx.com/en/faq/where-to-start-segmenting-a-flat-office-network

## How do I segment IT and OT with VLANs and access lists?

Use VLANs to separate the networks and a firewall, not only switch access lists, to control what crosses between them. Put production controllers, HMIs and SCADA servers in their own VLANs, place a firewall between them and the office network, and add a small DMZ for the systems both sides need, such as a historian copy or a remote-access gateway. Write the rules as an allow list: which office host may reach which OT host, on which port, and nothing else; deny and log the rest. Switch access lists are useful for simple separation inside OT, but they keep no connection state and are easy to get wrong at scale. Plan the change with the OT engineer and a maintenance window, because a missed dependency can stop a line. Then watch the boundary: from the Pro plan, NetSenX flags traffic that crosses levels of the plant network, from a SPAN or TAP port, without probing any OT device.

https://netsenx.com/en/faq/how-to-segment-it-and-ot-with-vlans-and-acls

## What is microsegmentation, and do small companies need it?

Microsegmentation means controlling traffic between individual servers or workloads, not only between network zones, so that two servers in the same segment cannot talk to each other unless a rule allows it. It is usually done with host firewalls, hypervisor or cloud security groups, or an agent that enforces policy on each machine. It is very effective against an intruder moving from one server to the next, and common in data centres and cloud environments. Most small companies get more from ordinary segmentation first: separate networks for guests, devices, users and servers. If you run many servers, the inexpensive version of microsegmentation is to switch on each server's own firewall and allow only the connections it needs. Whatever you choose, let real traffic guide the rules. The NetSenX network map shows which hosts talk to which on monitored segments, on every plan, and lateral movement alerts show sessions that do not match a host's normal.

https://netsenx.com/en/faq/what-is-microsegmentation

## Is a VLAN a security boundary?

Only when traffic between VLANs passes through a firewall or access rules that enforce something. A VLAN by itself separates broadcast domains on a switch; if the router between VLANs allows everything, the separation is cosmetic, and that is a common finding in small networks. Misconfigured switch ports can also let an attacker hop between VLANs, for example trunk ports left open to user devices, or the default VLAN used for everything. To make VLANs count: route between them through a firewall with an allow list, set user ports to a single access VLAN, disable unused ports, and keep management interfaces in their own VLAN. Then check that the rules hold with real traffic. NetSenX shows host-to-host connections on monitored segments and flags scanning and lateral movement on every plan, so a host that reaches across VLANs where it should not becomes visible, as long as that traffic crosses a mirrored link.

https://netsenx.com/en/faq/is-a-vlan-a-security-boundary

## How do I check that guest Wi-Fi cannot reach our internal network?

Join the guest network with a phone or laptop and try to reach internal systems: open the address of a file server, a printer's web page, the router's admin page and the office's internal name server. On your own network, a simple connection test or ping to internal address ranges shows whether anything answers. Then check the configuration: client isolation switched on, the guest network in its own VLAN or router port, internet access only, and the Wi-Fi system's admin interface not reachable from it. Repeat after every change to the Wi-Fi system, because firmware updates and new access points can reset settings. If the guest segment is monitored, NetSenX shows guest devices on the network map and flags any sessions from them to internal hosts, as well as scanning or lateral movement, on every plan. A guest device that reaches an internal server shows up as a connection that should not exist.

https://netsenx.com/en/faq/how-to-check-guest-wifi-cannot-reach-the-internal-network

## Is a separate guest Wi-Fi enough for security?

It is a good first step, but only if it is really separate and not the only separation you have. A guest network with its own name but the same address range and no rules between it and the office is not separate at all; check that it is isolated and offers only internet access. It also protects only against visitors: staff phones, smart TVs and the coffee machine often end up on the office network instead. Put personal and IoT devices on the guest network or a device network, keep company laptops on a network with certificate or per-user authentication, change the guest password regularly, and do not let the guest network reach the admin interfaces of the Wi-Fi itself. Then confirm with real traffic. If the guest segment is monitored, NetSenX lists its devices on the network map and flags any connections from them to internal hosts, scanning or lateral movement, on every plan.

https://netsenx.com/en/faq/is-a-separate-guest-wifi-enough

## Can someone plug a device into a free network socket in our office?

In most small offices, yes: a live socket in a meeting room, at reception or behind a printer gives whoever plugs in a device the same network access as a company PC. A small computer hidden there can call out to its owner and act as a door into the network for months. Close it with simple measures: disable switch ports and wall sockets that are not in use, put meeting rooms and reception on the guest network, use port security to allow only known devices on a port, or 802.1X so that a device must authenticate before it gets any access. Walk through the office now and then, and check the switches for unknown devices. NetSenX helps find what already got in: its network map lists devices seen on monitored segments, including ones without an agent, on every plan, and a hidden device that calls out at regular intervals is flagged as beaconing. A device that stays silent, or sits on an unmonitored segment, is not seen.

https://netsenx.com/en/faq/can-someone-plug-a-device-into-a-free-network-socket

## What is 802.1X, and does a small office need it?

802.1X is a standard that makes a device prove its identity before a switch port or Wi-Fi network lets it in, usually with a certificate or a user name and password checked by an authentication server. A device that fails gets no access, or lands in a restricted guest network. It is the strongest way to stop unknown devices from simply plugging in, and for Wi-Fi it replaces one shared password with per-user or per-device credentials, so that a leaver's access can be revoked on its own. It needs switches and access points that support it, an authentication server, which is often included in cloud identity or firewall products, and some care with printers and devices that cannot authenticate. Many small offices start with 802.1X on Wi-Fi only and port security on wired ports. NetSenX does not enforce network access; its network map shows the devices seen on monitored segments, on every plan, which helps you find the ones your access control missed.

https://netsenx.com/en/faq/what-is-802-1x-and-does-a-small-office-need-it

## Is multi-factor authentication enough to stop account takeover?

It stops most of it, but not all. Multi-factor authentication (MFA) blocks attacks that rely on a stolen or guessed password alone, which is why insurers ask for it and NIS2 lists it among its measures. Attackers have adapted: they use fake login pages that relay the code in real time, steal the session cookie after login, flood users with push requests until one is accepted, or talk the help desk into resetting a phone. Raise the bar: prefer phishing-resistant methods such as passkeys or hardware security keys, especially for administrators and finance; use number matching on push prompts; limit how long sessions last; and make the help desk verify identity before resetting MFA. Watch sign-in logs for risky sign-ins. A network sensor does not see sign-ins. What NetSenX shows is what a taken-over account's device does next on the network, such as lateral movement, scanning or large uploads, on every plan.

https://netsenx.com/en/faq/is-mfa-enough-to-stop-account-takeover

## Does a partial MFA rollout count for insurers and auditors?

Usually not as MFA in place, and an imprecise answer on a form can cause trouble later. Insurance questionnaires and auditors typically ask where MFA is enforced: e-mail, remote access, cloud applications, administrator accounts and backups. If MFA covers e-mail but not the VPN, or users but not administrators, say so exactly, because a claim investigation will check. Close the gaps attackers use most first: remote access, e-mail, admin accounts and the backup console, then the remaining cloud applications. Remove exceptions that are no longer needed, and document the ones you keep with a reason and an end date. Service accounts that cannot use MFA should be restricted to known sources and watched instead. NetSenX does not check MFA coverage; your identity provider reports it. What NetSenX adds to the evidence is network-side: an alert history with timestamps for monitored segments, kept for your plan's retention period.

https://netsenx.com/en/faq/does-a-partial-mfa-rollout-count

## Which MFA methods resist phishing?

Passkeys and hardware security keys based on the FIDO2 standard, and smart cards with certificates. They resist phishing because the key checks the web address it is talking to and will not answer a fake site, so there is no code for the user to type into the wrong place. Authenticator apps with number matching are a solid second choice; codes sent by text message and plain approve-or-deny push prompts are the weakest, because a convincing fake page or a tired user can hand them over. Start with the accounts that matter most: administrators, finance, executives and anyone with access to backups or customer data. Keep a spare key per person and a documented recovery procedure, so that a lost key does not lead to a hurried, insecure reset. MFA lives in your identity provider, not in the network. NetSenX does not see sign-ins; it shows what devices do on monitored segments after any account is used.

https://netsenx.com/en/faq/which-mfa-methods-resist-phishing

## What is MFA fatigue, or push bombing?

It is an attack in which someone who already has a user's password triggers sign-in after sign-in, so that the user's phone fills with approval requests, often at night, until the user taps approve to make it stop. Sometimes the attacker also calls or messages the user, pretending to be IT. It works against simple approve-or-deny push prompts. The defences are on the identity side: switch on number matching, so that the user must type a number shown on the login screen; show the location and application in the prompt; limit the number of prompts per minute; alert on repeated denied requests; and tell staff that an unexpected prompt means their password is known, so they should deny it and call IT. Better still, move key accounts to passkeys or hardware keys. A network sensor does not see these prompts. NetSenX shows what happens if an attacker gets in: unusual sessions, scanning or uploads from the user's device on monitored segments, on every plan.

https://netsenx.com/en/faq/what-is-mfa-fatigue-or-push-bombing

## Who holds admin rights in our company, and how do we check?

Usually more people and accounts than anyone thinks, so build the list from the systems themselves, not from memory. Check the administrator groups in your directory or cloud identity provider, the local administrators on PCs and servers, the admin roles in each cloud application such as e-mail, accounting and file sharing, the admin accounts of firewalls, switches, Wi-Fi and backups, and the accounts your IT supplier uses. Look for former staff, shared accounts, accounts that have not signed in for months and service accounts with admin rights. Then reduce: remove what nobody needs, give administrators a separate admin account, require phishing-resistant MFA on all of them, and repeat the review every quarter and whenever someone leaves. This is identity work, and a network sensor cannot list admin rights. NetSenX helps on the other side: it flags admin protocols used between hosts in ways that do not match their normal as lateral movement, on every plan.

https://netsenx.com/en/faq/how-to-find-out-who-has-admin-rights

## What does least privilege mean in practice?

It means that every person, account and system gets only the access it needs for its job, for as long as it needs it, and nothing more. In practice, for a small company: staff are not local administrators on their PCs; administrators use a separate admin account for admin work and an ordinary one for e-mail and browsing; file shares are open to the teams that use them, not to everyone; suppliers get access to the systems they support, switched on when needed; service accounts get only the rights their application needs; and access is reviewed when people change roles or leave. The payoff is that one stolen password or infected laptop reaches far less. It also cuts noise: unusual access stands out more when normal access is narrow. NetSenX watches the network side of this: it flags new sessions between hosts that do not match their normal as lateral movement, on every plan, which often reveals access nobody meant to allow.

https://netsenx.com/en/faq/what-is-least-privilege-in-practice

## Do service accounts and API tokens need monitoring too?

Yes, and they are often the least watched accounts in the company. Service accounts run backups, scans, integrations and scheduled jobs, often with broad rights, passwords that never change and no multi-factor authentication. API tokens and keys for cloud services sit in scripts, configuration files and code repositories, where an attacker who finds one can use it from anywhere. Keep an inventory with an owner for each, give them only the rights they need, store secrets in a vault rather than in files, rotate them on a schedule and immediately when someone with access leaves, restrict where they may be used from, and alert when one is used from an unusual place or at an unusual time; your identity and cloud logs show that. On the network, a service account is always used from some host: NetSenX flags that host when it starts new sessions to other hosts, scans or uploads unusually much, on every plan. It does not see the token itself inside encrypted traffic.

https://netsenx.com/en/faq/do-service-accounts-and-api-tokens-need-monitoring

## Are shared admin accounts a problem, and what should we do instead?

Yes. When several people use one admin account, nobody can tell afterwards who did what, the password is rarely changed when someone leaves, and multi-factor authentication is hard to bind to one person, so the account often goes without it. Give each administrator, including your IT supplier's staff, a personal admin account with phishing-resistant MFA, and remove or disable the shared one. Where a built-in account cannot be removed, such as the local administrator on PCs or the emergency account of a firewall, give each machine a unique random password managed by a tool, keep emergency credentials sealed, and alert when they are used. Log admin actions per person and review the list of admin accounts every quarter. A network sensor cannot tell which person used an account. NetSenX shows from which host admin sessions start and flags sessions that do not match a host's normal as lateral movement, on every plan, so a shared account used from an odd machine stands out.

https://netsenx.com/en/faq/how-to-handle-shared-admin-accounts

## Are password managers safe for a company to use?

Yes, for most companies they are far safer than the alternatives: reused passwords, spreadsheets and sticky notes. A good business password manager lets every person use long, unique passwords, shares team credentials without sending them by e-mail, and removes a leaver's access in one step. The vault becomes valuable, so protect it: require phishing-resistant multi-factor authentication for it, choose a provider that encrypts the vault so that the provider cannot read its content, check where your data is stored, block vault access from unmanaged devices if the product allows it, and keep the recovery procedure documented. Do not keep the password manager's own admin credentials only inside it. A password manager does not stop phishing on its own, though it helps, because it will not fill a password into a fake site. NetSenX does not see passwords or vaults; it watches what devices do on the network.

https://netsenx.com/en/faq/are-password-managers-safe-for-a-company

## What makes a good company password policy?

Length, uniqueness and multi-factor authentication, rather than complexity rules and forced monthly changes. NIST's Digital Identity Guidelines (SP 800-63B) favour long passwords, checking new passwords against lists of known-breached ones, and changing a password when there is evidence that it was compromised rather than on a fixed schedule, because forced periodic changes push people towards predictable patterns. In practice: a minimum length that allows passphrases, no reuse across systems, a password manager for everyone, blocking of breached and common passwords, lockout or slowdown after repeated failures, and MFA on everything that faces the internet. Admin and service accounts deserve longer, randomly generated passwords stored in a vault. Explain the reasons to staff; a policy people understand is followed more. NetSenX does not enforce passwords. On the network it flags repeated login attempts against monitored hosts as brute force, on every plan, which shows when someone is guessing.

https://netsenx.com/en/faq/what-makes-a-good-company-password-policy

## What is single sign-on, and does it improve security?

Single sign-on (SSO) lets people sign in once with a company account from an identity provider and then use many applications without separate passwords, usually through the SAML or OpenID Connect standards. Done well, it improves security: fewer passwords to reuse or steal, one place to enforce multi-factor authentication and device rules, one place to see sign-ins, and one switch to turn off when someone leaves, which closes access to every connected application at once. The flip side is concentration: the identity provider becomes the key to everything, so protect its admin accounts with phishing-resistant MFA, keep an emergency access account sealed, and watch its sign-in logs. Applications outside SSO keep their own passwords; list them so that offboarding does not miss them. SSO is identity infrastructure, not network monitoring, and NetSenX does not see sign-ins. It shows what devices do on the network after anyone signs in.

https://netsenx.com/en/faq/what-is-single-sign-on-and-does-it-improve-security

## How do we monitor an external accountant's remote access to our PCs?

Make the access narrow and visible first, then watch it. Agree in writing which PCs the accountants may reach, through which tool, at which times and with which accounts, ideally a named account per person with multi-factor authentication. Prefer a remote-access tool you control, with session logging, over one the accountant installed; enable it for the month-end window and switch it off afterwards. Keep the finance PCs on a segment that cannot reach the rest of the network. Ask the firm how it protects its own systems, because their compromise becomes yours. Then watch the pattern: the remote sessions appear on the network as connections from an outside address to specific internal hosts at specific times. NetSenX shows those connections and, if a session starts reaching other internal hosts, flags lateral movement, on every plan; a remote tool's regular check-ins outside the agreed window show up as beaconing. NetSenX does not manage who has access.

https://netsenx.com/en/faq/how-to-monitor-an-external-accountants-remote-access

## What happens if our outsourced IT provider or bookkeeper is hacked?

Their access becomes the attacker's access. An IT provider usually holds admin rights to your servers, remote-management tools on every PC and passwords to your cloud accounts; a bookkeeper may have remote access to the finance PCs and your banking portal. Attackers know this, and some large incidents have spread from one service provider to many of its customers. Prepare before it happens: list every supplier with access and what they can reach, require named accounts with multi-factor authentication, limit their tools to the systems they support, ask how they protect their own environment and how they will tell you about an incident, and write those duties into the contract, which NIS2 also expects as part of supply-chain security. Agree how you would cut their access in an emergency. NetSenX shows the supplier's connections into your network and flags lateral movement, scanning, beaconing and unusual outbound volume from the hosts they use, on every plan. It does not monitor the supplier's own systems.

https://netsenx.com/en/faq/what-happens-if-our-outsourced-it-or-bookkeeper-is-hacked

## How do I find old remote-access tools that suppliers left on our servers?

Combine the software inventory with the network traffic. On each server, list installed programs and running services and look for remote-desktop and remote-support tools, VPN clients and agents of remote-management platforms; ask each supplier which tools they installed, when, and whether they still use them. On the network, look for what those tools do even when idle: regular check-ins to the vendor's relay servers, or connections from a cloud address that nobody on your side can explain. Remove what is no longer needed, move what is needed behind your own controlled access path, and change the passwords the supplier knew. NetSenX flags the regular check-ins as beaconing on every plan, and lists outside destinations on rented cloud servers in its review queue, where you confirm them, mark them suspicious or leave them for later. When the agent runs on the server, the alert also names the local program.

https://netsenx.com/en/faq/how-to-find-old-remote-access-tools-suppliers-left-on-servers

## How do we control and monitor third-party vendor access to our network?

With one controlled path, named accounts and a record of every session. Keep a register of suppliers with access: who they are, which systems they reach, through which tool and under which contract. Route all supplier access through a gateway, VPN or bastion host that you own, with multi-factor authentication and a personal account per technician; switch access on for agreed windows and off afterwards; and log or record sessions. Review the register every quarter and remove access that is no longer used. Require suppliers to tell you about incidents on their side, and test that you can cut their access quickly. On the network, supplier sessions should then start only from that one path. NetSenX shows the connections, flags lateral movement and scanning from the hosts suppliers use, on every plan, and lists outside destinations on rented cloud servers in its review queue, so a tool that bypasses your path becomes visible.

https://netsenx.com/en/faq/how-to-monitor-third-party-vendor-access

## What does NIS2 supply-chain security mean in practice for a small company?

It means managing the cyber-security risks that come from your suppliers and service providers as part of your own risk management. Directive (EU) 2022/2555 lists supply-chain security among the measures in its Article 21, including the security of relationships with direct suppliers and service providers. In practice, for an entity in scope: know which suppliers have access to your systems or data, assess how critical each one is, require basic security measures and incident notification in contracts, limit and control their access, and review all this regularly. If you supply an entity in NIS2 scope, expect to be asked for similar evidence even if NIS2 does not apply to you directly. National transpositions can add detail, so check your own country's law. NetSenX does not assess suppliers. It shows what their access does on your monitored network: connections, lateral movement, scanning and beaconing from the hosts they use, on every plan.

https://netsenx.com/en/faq/what-is-nis2-supply-chain-security-for-a-small-company

## How would we notice that a former employee's device is still connecting?

Mostly through accounts, partly through the network. On the identity side: disable the person's accounts on the last day, revoke VPN certificates and application sessions, remove their devices from device management, change shared passwords they knew, and check for mail forwarding rules and personal devices registered for MFA. Then watch the sign-in logs for that account and alert on any use. On the network side, a device that still has access, such as a personal phone with the office Wi-Fi password or a home PC with a saved VPN profile, shows up when it connects: the NetSenX network map lists devices seen on monitored segments with first and last seen, on every plan, so a device you thought was gone appears again, and the VPN view lists tunnels and gateway sessions. Change the Wi-Fi password, or better, use per-user Wi-Fi credentials, so that a leaver's devices cannot rejoin. NetSenX watches devices, not people, and does not track a former employee.

https://netsenx.com/en/faq/how-would-we-notice-an-ex-employees-device-still-connecting

## How can we tell if a stolen password is being used?

Mainly from sign-in logs, because they record who signed in, from where and how. Look for sign-ins from new countries, unfamiliar devices or hosting providers, successful sign-ins right after many failures, newly registered MFA methods, new mail forwarding rules, and access to applications the person never uses. Most identity providers and cloud office suites can flag risky sign-ins; switch this on and make sure someone reads the alerts. Check public breach notification services for your company domain, and act on what they report by resetting the password and checking for reuse. The network shows the second half: what the attacker does with the account. NetSenX flags lateral movement, scanning, beaconing and unusual uploads from devices on monitored segments, on every plan, which is often how an account takeover becomes visible inside the company. It does not see the sign-in itself, and it does not read passwords.

https://netsenx.com/en/faq/how-to-detect-a-stolen-password-being-used

## Should administrators use separate accounts for admin work?

Yes. An administrator who reads e-mail and browses the web with an admin account exposes the keys to everything to every phishing message and malicious website. With a separate admin account, used only for admin tasks and never for e-mail or browsing, a compromised everyday account gets the attacker much less. Go further where you can: require phishing-resistant MFA on admin accounts, use them only from a dedicated admin workstation or a bastion host, give each admin account only the rights for the systems it manages, and disable admin accounts that have not been used for months. This applies to your IT supplier's staff as well. It is identity hygiene that a network tool cannot enforce. It does make monitoring sharper, though: when admin sessions are expected only from one workstation or bastion, NetSenX flags admin protocols used from other hosts as lateral movement, on every plan.

https://netsenx.com/en/faq/should-admins-use-separate-accounts-for-admin-work

## What is privileged access management (PAM), and do we need it?

Privileged access management (PAM) is a set of tools and practices for controlling the most powerful accounts: administrators, root, service accounts and emergency accounts. Typical features are a vault that stores and rotates admin passwords, check-out of credentials for a limited time, session recording, approval before access, and just-in-time rights that exist only while a task is done. Full PAM products suit larger companies and regulated environments. A small company can cover the essentials without one: an inventory of privileged accounts, separate admin accounts with phishing-resistant MFA, unique local administrator passwords managed by a tool, a bastion host for remote admin access, and a quarterly review. Choose a PAM product when the number of administrators, suppliers or audit demands makes that manual work unreliable. NetSenX is not a PAM tool. It complements one by showing where privileged sessions happen on the network and flagging those that do not match a host's normal as lateral movement, on every plan.

https://netsenx.com/en/faq/what-is-privileged-access-management

## Can network monitoring see attacks on accounts and the directory?

Partly, and NetSenX less than you might expect. Many identity attacks happen inside sign-in systems: password spraying against cloud accounts, phishing of MFA codes, stolen session tokens and abuse of directory permissions. Those leave traces in identity provider, directory and cloud logs, not on your office network, so the tools that read those logs, such as the identity provider's risk detection, an EDR or a SIEM, are where they are caught. Some directory attacks do cross the network, such as one workstation suddenly requesting many service tickets from the domain controller, and specialist tools watch those protocols. NetSenX does not raise alerts on identity events. What it sees is the device behaviour around them: repeated login attempts against monitored hosts as brute force, and the lateral movement, scanning and beaconing that follow a compromised account, on every plan. Use it beside your identity logs, not instead of them.

https://netsenx.com/en/faq/can-network-monitoring-see-identity-attacks

## Does NIS2 require zero trust?

No, NIS2 does not name zero trust, but several of its required measures point the same way. Article 21 of Directive (EU) 2022/2555 asks entities in scope for risk-based measures that include, among others, access control policies, asset management, the use of multi-factor or continuous authentication, secured communications and supply-chain security. Zero-trust practices, such as verifying each user and device, granting least privilege and segmenting networks, are one practical way to meet those measures, but the directive leaves the method to you, and national transpositions and guidance may add detail; check your own country's law. What auditors look for is a documented risk assessment, measures that match it, and evidence that they work. NetSenX contributes evidence on the network side: which hosts talk to which on monitored segments, and alerts on lateral movement, scanning and beaconing, on every plan. It does not make you compliant.

https://netsenx.com/en/faq/does-nis2-require-zero-trust

## How do we limit what a compromised laptop can reach?

Assume one laptop will be compromised and decide in advance how little it should be able to touch. Ordinary laptops rarely need to talk to each other, so block laptop-to-laptop traffic with the client firewall or switch settings; let them reach servers only on the ports their applications use; keep backups, management interfaces and the domain controller's admin paths out of their reach; and make sure the user is not a local administrator, so that malware cannot easily switch off protection or harvest other accounts' passwords. On the VPN, give each group access only to what it needs. Then check the result with real traffic, because a rule set on paper often has gaps. NetSenX shows which hosts talk to which on monitored segments and flags new host-to-host sessions that do not match a laptop's normal as lateral movement, along with scanning and beaconing, on every plan, so you see where a compromised laptop could still reach.

https://netsenx.com/en/faq/how-to-limit-what-a-compromised-laptop-can-reach

## Should our servers be allowed to connect to any address on the internet?

No. Most servers need a short list of outbound destinations, such as update servers, a backup target and a few partner services, and nothing else. Unrestricted outbound access is what lets malware on a server call home, download tools and upload stolen data. Restrict it with egress filtering on the firewall: allow the destinations each server needs, route web access through a proxy if you have one, and deny and log the rest. Start in logging mode for a few weeks to find what the servers really use, then tighten. Domain-based rules are easier to maintain than lists of addresses, because cloud services change their addresses. The same applies to printers, cameras and OT devices. NetSenX shows which outside destinations monitored hosts connect to, flags beaconing and unusual outbound volume on every plan, and lists destinations on rented cloud servers in its review queue, which gives you the list you need to write the rules.

https://netsenx.com/en/faq/should-servers-be-allowed-to-browse-the-internet

## How do we write segmentation rules without breaking things?

Base them on observed traffic, introduce them in stages and keep a way back. First record who actually talks to whom for a few weeks, including the jobs that run rarely: backups, payroll, month-end reports, the scanner that saves to a share. Draft allow rules from that, review them with the owner of each system, and decide which observed connections should not exist at all. Then set the firewall to log what the new rules would block, without blocking, and investigate each hit. Only after that, enforce, one segment at a time, with a rollback plan and someone on hand. Keep the rule set documented, with a reason and an owner for each rule. The NetSenX network map shows host-to-host communication on monitored segments, on every plan, which is the observed-traffic picture this method needs, and its lateral movement alerts afterwards show sessions that do not match the new normal.

https://netsenx.com/en/faq/how-to-build-allow-rules-from-real-traffic

## Is a DMZ still useful for a small company?

Yes, whenever you host something that the internet or another untrusted network must reach. A demilitarised zone (DMZ) is a separate network segment between the outside and your internal network, where you put systems that must accept outside connections, such as a web server, a mail relay, a remote-access gateway or a file-transfer server. If one of them is compromised, the attacker is in the DMZ, and firewall rules stop them from opening connections into the internal network. The same idea separates office and production networks in factories. Many small companies no longer host public services themselves, and then the DMZ is small or unnecessary; but the moment you forward a port to an internal server, you have a DMZ problem without the DMZ. Keep DMZ hosts patched and minimal, and allow only the specific inward connections they need. On a monitored segment, NetSenX flags lateral movement and scanning from a DMZ host towards internal hosts, on every plan.

https://netsenx.com/en/faq/is-a-dmz-still-useful

## Can we segment a small office network without buying new hardware?

Often, yes, at least in part. Check what you already have: many business routers and firewalls support VLANs and rules between them, many managed switches do too, and most Wi-Fi systems can run a separate guest network with client isolation. If your switches are unmanaged, start with what does not need them: a guest Wi-Fi with isolation for visitors and personal devices, the host firewall on every PC and server set to allow only what is needed, laptop-to-laptop traffic blocked, and file shares limited to the groups that use them. Replace unmanaged switches gradually, starting where servers and backups sit. Write down what you separated and why, so that the next person does not undo it. Then check that it works with real traffic. NetSenX shows which hosts talk to which on monitored segments, on every plan; one agent on a SPAN or TAP port, which needs a switch that can mirror or a TAP, counts as one device for that segment.

https://netsenx.com/en/faq/how-to-segment-a-small-office-without-new-hardware

## How do we protect our domain controller or directory server?

Treat it as the most valuable system you have, because whoever controls it controls every account. Limit who can log in to it: only a few personal admin accounts with phishing-resistant MFA, used from a dedicated admin workstation and never for e-mail or browsing. Keep it patched, run nothing else on it, block its internet access except for what it needs, and let ordinary PCs reach it only on the ports that authentication requires, not for remote desktop or admin shares. Keep an offline, tested backup of the directory and a documented recovery plan, because rebuilding a directory under pressure is hard. Review admin group membership regularly, and watch the directory's own security logs with a tool that reads them. On the network, NetSenX flags new sessions to the domain controller that do not match a host's normal, such as a marketing PC opening a remote session at night, as lateral movement, on every plan. It does not read the directory's logs.

https://netsenx.com/en/faq/how-to-protect-the-domain-controller

## Does zero trust mean monitoring employees?

No. Zero trust is about not granting access on trust alone: every device and account proves itself, gets only what it needs, and its access is checked continuously. That concerns devices, accounts and connections, not people's work, and it does not require reading anyone's content. It does involve logging, such as sign-ins, device health and network connections, so be transparent: tell staff what is logged, why and for how long, involve the works council where there is one, and carry out a data protection impact assessment where the law requires it. Keep the data minimal and the purpose limited to security. NetSenX is built that way: it watches devices and connections, not people, analyses connection metadata to detect attacks, never decrypts traffic and does not score or rank employees. Its alerts name hosts and addresses; when an alert needs a person's context, that step stays within your own process.

https://netsenx.com/en/faq/does-zero-trust-mean-monitoring-employees

FAQ: https://netsenx.com/en/faq