If everyone who can walk into the building can also join the network, the defences at the perimeter lose most of their value. NAC closes that gap: every device that touches a socket says who it is first, and sees only as much network as its authorisation allows.
Done Dynamics delivers network access control projects: 802.1X authentication, RADIUS server setup, device profiling and posture with Cisco ISE, dynamic VLAN assignment, guest network portals and BYOD onboarding. Offices, hotels, hospitals, factories and multi-site businesses — on site around Alanya and Antalya, remotely across Istanbul and the rest of Turkey.
The problem NAC solves fits in one sentence: the network has no idea what has been plugged into it. A company laptop, a contractor machine, an IP camera in the lobby, an employee personal phone and whatever a visitor connected in the meeting room all sit on ports of the same switch, and the network hands every one of them the same thing. Access control turns that threshold into a door where a credential is required.
This page is a deployment plan rather than a product brochure. Below we explain how 802.1X actually works, what each authentication method really costs you, how devices that cannot speak it are handled, and why the rollout has to begin in monitor mode. The segmentation and rule management side is covered separately in network security and VLAN segmentation. If you are looking at a cloud-managed access layer, the Cisco Meraki page is worth reading alongside this one.
These six situations barely change from one organisation to the next. What they share is simple: they all attach to the same access layer, and they all receive the same trust.
Almost every organisation has one: a cable end under the table that nobody tracks, running straight into an access switch. Plug a laptop into it and the network asks no questions. An address is handed out, a gateway, a DNS server. From that moment the visitor machine is an internal device that can reach the accounting server, and no record of it exists anywhere.
A technician arrives for maintenance carrying their own machine. Nobody knows its patch level, what is running on it, or which network it was joined to yesterday. The network cannot tell it apart from a company-owned laptop, so it grants exactly the same trust. This is the single most common infection path we see in the field, and it costs nothing to arrange.
These devices are installed once and never touched again. Their firmware goes unpatched for years and default credentials often survive. They also sit in the most physically exposed places in the building. Unplugging a camera in a stairwell and putting a laptop on that cable takes a couple of minutes, and on a flat network nobody notices it happened.
Once the wireless passphrase is learned it spreads through the organisation and then beyond it. If wireless access rests on a single shared secret, everyone who has ever heard it is inside. Former staff can remain connected months after leaving, because changing the passphrase means reconfiguring hundreds of devices — which is exactly why it never gets changed.
Barcode scanners, scale computers, control panels on the production line. They cannot speak modern authentication, the business cannot run without them, and nobody wants to experiment on them. This is where NAC projects usually stall. The answer is not to exclude these devices from scope; it is to bind them to a separate, deliberately narrow rule.
A five-port switch a department bought and put on a desk. It turns one socket into five, appears in no inventory, and nobody remembers who installed it. On a network without access control it is an invisible expansion point. On a network with access control it shows up on day one and gets recorded, which is often the first tangible benefit the client sees.
Reading that list and thinking "we have those too" is easy. Knowing how many you have is the hard part. In nearly every network we inherit there is a visible gap between the device count in the inventory and the number of devices actually generating traffic. That gap is not the product of bad intent; it is the product of time. Devices were added over years, the people who added them moved on, and nobody kept the record.
In enterprise network security discussions, attention usually concentrates on the perimeter — the firewall, the services published to the internet. But the perimeter answers the question of whether someone got in. Access control answers who is allowed onto the network at all, and segmentation answers how far they can travel once they are on it. The three do not substitute for one another, and in most organisations the second one has never been answered.
Port security exists on virtually every managed switch and takes a few lines to configure, which is why it gets chosen instead of NAC so often. Each port is told which MAC addresses are permitted, and it shuts if anything else appears. Reasonable on paper; it fails in the field in four distinct ways.
It is better understood as a housekeeping tool that catches accidental cabling mistakes than as a security control. Against a device connected on purpose, its value is limited.
A MAC address can be changed in one command
Setting a network card to a different MAC address requires administrator rights and a single line. Reading the address of a printer sitting on the network needs no special tooling at all: most printers publish it on their own web interface, and many print it on a sticker on the casing. An attacker copies that address onto their own adapter and the port opens. Port security raises no alarm in this scenario, because what it sees is precisely the address it was told to expect.
The administrative burden collapses within months
In a two-hundred-person organisation, every new laptop, every failed network card, every desk move is a record to update. The first month is disciplined, the third month slips, and by the sixth nobody touches it. That is why most of the port security configurations we inherit have either been disabled outright or quietly neutered by raising the permitted address count per port until the rule means nothing.
It validates a cable, not an identity
MAC-based control knows which address appeared on which port. It has no concept of a user. The finance director laptop and an intern laptop plugged into the same socket receive identical treatment. Per-user authorisation, per-user VLAN, per-user logging — none of it is possible, which means none of the questions an auditor actually asks can be answered from it.
The violation behaviour hurts the business
On a violation, port security shuts the port and waits for manual intervention. In practice that means an employee loses a morning because someone plugged the wrong device in, and IT has to walk to the floor every time. After a few rounds of this the rule is relaxed or removed. A control that gets switched off under operational pressure is not a control.
802.1X treats the port as a closed door. When a device is connected the switch does not hand out an address; it opens the port to authentication messages only and drops everything else. That conversation runs across the local network as EAP over LAN (EAPoL) frames. The switch does not evaluate it — it carries the exchange to the authentication server behind it over RADIUS, and applies whatever decision comes back.
This three-part structure is the key to understanding NAC design, because it tells you where a given problem lives. A device that cannot present a credential is a supplicant problem. A port that never asks for one is a switch configuration problem. A valid identity receiving the wrong authorisation is a policy set problem. Teams that blur those three spend days looking at the wrong device.
The side asking to join
The software on the device that wants network access. Windows, macOS and Linux all ship with it built in; in a managed estate it is configured centrally and pushed out. This is the component that presents the credential — a certificate, or a username and password. Supplicant configuration is the most labour-intensive and the most consistently underestimated line item in a NAC project.
The side holding the door
The access switch or wireless controller the device connects through. It does not authenticate anything itself; it relays. Until the port is authorised it passes only authentication traffic and drops everything else. It then applies whatever the decision server returns: open the port, place it in a named VLAN, install a downloadable access list on the session, or refuse.
The side making the decision
A server speaking RADIUS — Cisco ISE, FreeRADIUS or another. It consults the identity source (Active Directory, LDAP, a certificate authority), evaluates the policy set and tells the switch what to do. All of the intelligence lives here; the switch only enforces. Understanding this split is the foundation of NAC design, and teams that miss it spend the whole project troubleshooting the wrong box.
A successful authentication does not simply return "accept". The response also carries which VLAN the device should be placed in, which access list should be installed on the session, and how long before the session is re-evaluated. That is the mechanism behind dynamic VLAN assignment: the identity of a port is no longer a fixed line in the switch configuration but something determined afresh on every session.
The same structure applies on the wireless side. The access point takes the authenticator role, the conversation reaches the same server, and the same policy set is evaluated. Whether a user connected by cable or by radio does not change their authorisation — which is precisely the outcome we design for, and the one that makes an access review meaningful.
This is where the correct answer and the popular answer diverge. Certificate-based authentication is stronger; password-based authentication gets picked more often because it is easier to stand up.
Client and server certificates
Both sides present a certificate to each other. There is no password anywhere in the exchange to share, phish, reuse or leak. When a device is lost the corresponding certificate is revoked and that device is off the network within the hour. When the private key is stored so it cannot be exported from the machine, copying the credential onto another device stops being practical rather than merely being discouraged.
The cost: You need a certificate authority, an automated issuance and renewal path, and a calendar that tracks expiry. The setup effort is real and it lands before go-live. What you get in return is a quiet operational life afterwards.
Server certificate plus user password
Only the server presents a certificate; the username and password travel inside the resulting encrypted tunnel. Because it reuses the directory passwords an organisation already has, it needs no new infrastructure, and that is why it is chosen so often. The critical detail is this: if server certificate validation is not enforced on the client, a rogue access point can impersonate the authentication server and harvest credential hashes.
The cost: The validation setting has to be correct on every single device, and doing that by hand does not hold at scale. Beyond that, a password is a shareable thing — one user credential also puts another person device on the network, and no log will tell you it happened.
Various inner methods inside a tunnel
These appear in mixed estates, particularly where a large share of clients are not Windows. They serve as a workable bridge until a certificate infrastructure is in place. Behaviour resembles PEAP, and the same warning about server validation applies with equal force.
The cost: Client support varies by vendor and operating system version. Covering every device in a mixed fleet with a single method becomes difficult, and the policy set grows more complex than it needs to be.
Our practical advice is this: target EAP-TLS for corporate machines. Where no certificate infrastructure exists yet and the schedule is tight, we write a two-stage plan that starts on PEAP and moves to certificates. But if the date for that second stage is not fixed at the beginning, it never arrives — most of the PEAP deployments we encounter in the field began as a temporary measure and have been running that way for years.
When PEAP is chosen, the one thing we do not compromise on is that server certificate validation is enforced on the client and the trusted authority is named explicitly. A PEAP network built with that setting disabled becomes something built to protect the password that instead makes the password collectable. The only reliable way to be sure the setting is right on every device is central distribution; hand configuration does not survive at this scale.
Every network contains a population of devices that cannot do 802.1X, and that population is not shrinking. MAC Authentication Bypass opens a side door for them. How carefully that side door is built is the detail that separates a serious NAC project from a decorative one.
The five points opposite describe how we use MAB without turning it into an open door.
For a network that only wants to answer "who is this", a plain RADIUS server is enough. What separates ISE is that it also weighs what the device is and what condition it is in.
ISE works out what a device is on its own: the fingerprint inside its DHCP request, HTTP user agent, open ports, the vendor prefix on the MAC address, DNS and NetFlow data. The result is a sourced classification rather than a guess. Seeing the real inventory for the first time is usually the most striking moment of the project, because devices nobody remembers installing appear on the list.
A verified identity does not mean a healthy machine. Posture asks, at connection time, whether anti-malware is running, whether its signatures are current, whether the disk is encrypted and what patch level the operating system is at. A device that fails is placed into a remediation segment where it can reach only the update servers, and moves to the normal network once the condition is satisfied.
Which VLAN a port belongs to stops being a static line in the switch configuration and becomes an outcome of authentication. The same socket lands finance staff in the finance segment, field staff in the field segment, and an unrecognised device in quarantine. Office moves stop being switch configuration work, which quietly removes a whole category of ticket from the helpdesk.
A VLAN is a blunt instrument: everyone inside it can see everyone else. A dACL goes further and installs a session-specific access list onto the authorised port. Port and destination limits can be written per user. Instead of accumulating hundreds of static access lists across the access layer, the rule lives centrally and is updated centrally.
An approach that decouples authorisation from IP addressing. Every authenticated session receives a tag, and rules are written between tags rather than between address blocks: the contractor tag cannot talk to the production tag. When the address plan changes, the rule set does not have to be rewritten. Conceptually strong, but it requires end-to-end support across the estate, so we do not put it on the day-one agenda for every network.
A visitor joining the wireless network lands on a splash page. The account is either self-registered in a short form or created by a member of staff acting as sponsor, with a defined lifetime. It expires by itself when that lifetime runs out. This is the end of handing out a shared passphrase and watching it circulate for years afterwards.
A controlled path for staff connecting their own phone or tablet. The device is redirected into an onboarding flow on first connection, the user authenticates with their corporate identity, the device is issued its own certificate and enters the inventory bound to that person. When someone leaves or a handset is lost, a single record is revoked; nobody has to change a shared secret.
Who connected, on which device, through which port of which switch, at what time, and which policy was applied — all on one screen. During an incident investigation the difference between having this record and not having it is the difference between hours and days. Retention period and access rights for these logs are agreed as part of the deployment, not afterwards.
This is the most important section on the page. What failed NAC projects have in common is not technical weakness; it is that these three phases were skipped. A deployment that starts directly in closed mode goes like this: hundreds of devices are stranded, the helpdesk seizes up, the configuration is rolled back before lunch, and the phrase "NAC did not work here" circulates in that organisation for years. What did not work was the sequence.
Learn what is actually on the network without closing a single port. Authentication runs and results are logged, but a device that fails still gets onto the network. Users notice nothing at all, which is exactly the intent.
What we watch: How many devices fail and why; which machines have no supplicant configured at all; which MAC addresses match no profile; which ports show more than one device; and how far the real printer and camera inventory diverges from the documented one.
How long we stay: Typically several weeks. The measure is not the calendar but the log curve: you stay here until new and unexplained devices stop appearing and the failure list approaches zero. Leaving early is a debt that gets paid in the next phase, with interest.
A narrow access list sits on the port from the start. Before authentication only essential services are reachable — DHCP, DNS, domain controllers, patch servers. On successful authentication the authorisation widens. A device that fails is not thrown off the network, but it can see very little.
What we watch: The behaviour of machines that boot from the network via PXE; the first boot of newly domain-joined machines; whether wake-on-LAN still works; what happens on meeting room and training room ports. We track the type of complaint rather than the count — every complaint is a missing line in the policy set.
How long we stay: Anywhere from several weeks to a few months. This is the phase where mistakes surface before enforcement, and it is the one part of the programme that should never be compressed to hit a date.
An unauthenticated device does not get onto the network. The port passes nothing but authentication traffic until an authorisation result arrives. This is the state NAC promises, and it is only painless when the previous two phases were run properly.
What we watch: The transition is done floor by floor or department by department, never across the whole building in one night. After each wave, session logs and helpdesk tickets are read together. The next wave opens only once the complaints from the previous one have been closed out.
How long we stay: The steady operating state. The policy set keeps evolving as new device types arrive; this is a structure that is maintained, not a project that ends.
The value of what monitor mode collects is inventory before it is security. The list produced in the first week is usually surprising: servers nobody remembers, old camera recorders still sitting on the network, dozens of mobile devices that appear in no register. Moving to enforcement before that list is reconciled means locking a network you do not yet understand.
In the second phase what matters is the type of complaint rather than the count. Every complaint points at a missing line in the policy set. When the same kind of complaint arrives twice, a rule gets written; when it stops arriving, the next wave opens. That is why we do not commit to a day-by-day calendar — the log curve sets the pace. Closing a network that is not ready in order to hit a date costs more than restarting the project would.
These subjects usually come up after go-live, on the night of the first incident. We answer them before deployment and put the answers in writing.
This answer belongs in the design document, not in the post-incident review. If the switch does not know what to do when no RADIUS response arrives, its default behaviour is to keep the port closed — meaning the loss of one server becomes the loss of the whole network. With critical authentication configured, the switch places ports into a predefined VLAN while the server is unreachable and work continues. When the server returns, sessions are re-evaluated.
The scope of the critical VLAN is a security decision in its own right. Granting full access turns taking down the server into a deliberate bypass technique. Granting nothing turns a server outage into a network outage. In practice we open it to the minimum set of services the business needs to keep operating — file servers, line-of-business applications, printers — while management interfaces and sensitive segments stay closed.
Once network admission depends on one server, that server is the most critical component you own. We plan for at least two nodes, ideally in two physical locations. Backup, upgrade windows and certificate renewal are scheduled from the outset. Walking into a first version upgrade without knowing what it does to live sessions is a night most organisations experience exactly once.
The classic desk layout: one socket, a phone in the socket, a computer behind the phone. That port now carries two devices and both must authenticate separately. With multi-domain authentication the phone authenticates in the voice domain and the computer in the data domain, and each lands in its own VLAN. Configure it wrongly and either the phone works or the computer does — never both.
For teams that build machines by booting them from the network, this single detail can stop a project. At boot time there is no supplicant yet and the machine has nothing to present. The answer is a dedicated policy for the build ports or the addresses in use during that window, with the device moving into the normal flow once imaging completes. Teams that go closed without planning for this find their build room dead the following morning.
Waking a powered-off machine over the network to push patches is a common management habit. On an unauthorised port the magic packet may never reach its target. This scenario is tested before it is discovered the hard way. Where needed, the port is configured to permit traffic in a specific direction while unauthorised, or the patch window is triggered by another mechanism entirely.
These ports do not see company devices; they see a constantly changing population of visitor hardware. In closed mode a visitor laptop can never authenticate, so the port stays shut and the meeting stalls. The correct construction is a policy that hands these ports the guest segment automatically on authentication failure: internet egress, no internal access, and a session record kept.
Some of the access layer will not support the features required, or will be running a software release that is past support. This surfaces during discovery and it defines the hardware line of the proposal. Squeezing partial support out of an ageing switch produces behaviour that is very hard to explain six months later, so we say up front which units need to be replaced rather than discovering it during rollout.
Access control is useful in proportion to how well it talks to the rest of the estate. The identity source, the wireless controller, the firewall and the monitoring platform are planned as parts of one policy rather than four separate projects.
It is unusual to write this on a sales page, but it is the truth: in a forty-endpoint office, a solution the size of ISE brings more weight than the problem it removes.
Where it fits: A predominantly Cisco access layer, several hundred endpoints or more, a genuine need for posture assessment and detailed profiling, and an expectation that guest and BYOD flows are managed from the same product as wired and wireless authentication.
Watch out for: It is sized against endpoint count and licensed in tiers: basic authentication and guest functions sit at one level, while advanced capabilities such as profiling and posture sit higher up. On a small network that cost is usually unjustified. Because the vendor revises the licensing structure periodically, we verify the current tiers and sizing with you at the start of the project rather than quoting figures on a web page.
Where it fits: Where authentication itself is the requirement: 802.1X, EAP-TLS, directory integration, VLAN assignment. Suited to organisations with capable server-side people, or to those who hand operation of it to us.
Watch out for: Do not expect a ready-made management console, a profiling engine, posture assessment or a packaged guest portal. Some of these can be assembled from additional components, but the integration work falls to you or to us. There is no licence cost; there is an operating cost, and it is honest to say so.
Where it fits: Mid-sized networks that want an open-source NAC interface with a guest portal and basic profiling. Useful where the switch fleet spans several vendors, since it avoids tying access control to a single manufacturer.
Watch out for: Deployment and tuning take real effort, and the depth of support varies by switch model. The product is mature, but without a commercial support contract behind it the operational responsibility sits entirely with whoever runs it.
Where it fits: Organisations whose access layer and wireless estate are predominantly Aruba. The capability set overlaps substantially with ISE; profiling, guest and BYOD flows are mature.
Watch out for: The assessment follows the existing estate. Whichever vendor the majority of the network already comes from, that vendor NAC product usually generates less friction. We treat this as a practical question rather than an ideological one, and we will say so when the answer points away from Cisco.
Sizing turns on two variables: how many endpoints are concurrently on the network, and which capabilities will actually be used. A deployment doing authentication alone does not consume the same resources as one running profiling, posture assessment and BYOD onboarding together. On the ISE side licensing is tiered — basic authentication and guest functions sit at one level, with advanced capabilities such as profiling and posture positioned above. Because the vendor revises that structure from time to time, we do not print prices or package names here. We verify the current arrangement with you at the start of the project, and we tell you what you need in order not to buy a tier you will never use.
Where endpoint counts are modest and the requirement is authentication plus VLAN assignment, a RADIUS server setup built on FreeRADIUS delivers most of the same security gain with no licence cost. Add a guest portal and basic profiling to the requirement and PacketFence enters the picture. We say this not out of modesty: a badly sized NAC becomes unmanageable and gets switched off within a few years, and at that point you have neither the investment nor the security.
Six steps. The last one matters as much as the rest: your own team has to be able to run this.
Access switch models, software versions and feature support; the state of the wireless controller; the structure of the identity source; the device categories present on the network and their approximate counts. The output is an inventory and a suitability report. What can be done with today hardware and what requires new hardware becomes clear here, before anyone commits to a date.
Where user and device identity will come from, how groups translate into policy, how the certificate authority is built if certificates are used, and which tool distributes them. The certificate lifecycle — issuance, distribution, renewal, revocation — is written down with owners. Skip this step and the project returns a year later in the form of mass expiry.
Which user lands in which segment, which device class receives which authorisation, what happens on a failed authentication, how the guest flow runs, and for which devices MAB is enabled and under what restriction. The policy set is approved as a document before configuration begins; a policy first debated on a console screen never gets finished.
Every flow is exercised in a bounded area — a handful of ports, a handful of device types. Correct user, wrong user, unregistered device, IP phone with a PC behind it, server unreachable. Expected behaviours are recorded in a test matrix and compared against what actually happens, and the matrix is handed over with the rest of the documentation.
From monitor mode through low-impact to closed mode; waves by floor or by department; logs read and the policy set corrected after each wave. We do not commit to a day-by-day calendar for this, because progress is set by measurement — the data from one wave is what opens the next.
The policy set written out with the reasoning behind each decision, configuration backups, a guide to reading the logs, and step-by-step resolutions for the typical failure scenarios. Then a hands-on handover to the client own team: how a new device is added, how a guest account is issued, where to look when a user cannot get on. The aim is that the organisation is not dependent on us. Support is available if wanted, not because it is unavoidable.
Our engineers hold Cisco CyberOps Associate certification and CCNA-level network training. Those are individual certifications; we make no claim to a corporate vendor partnership. What we sell is design, deployment, phased rollout, documentation and handover. Where licences or hardware are required we run that as a separate and transparent line, and we point you to the vendor own channels where that is the correct route.
Documentation and training sit at the end because they are the most frequently skipped item. A team that does not know why a policy was written the way it was removes that policy at the first difficulty. What we hand over is not a folder of screenshots: it is the reasoning behind each policy decision, a guide to reading the logs, step-by-step resolutions for the common failure scenarios, and the procedure for adding a new device type. Support afterwards is available if you want it, not because you are stuck with us.
Not when it is phased. The work starts in monitor mode: authentication runs and results are logged, but a device that fails still reaches the network. For the first weeks nothing changes for users, while we learn what is actually out there. Low-impact mode follows, and closed mode comes last. Almost all disruption risk comes from skipping that order — projects that start directly in closed mode leave hundreds of devices stranded on the first morning and are usually rolled back the same day. Our progress measure is the log curve rather than the calendar: we do not move to the next phase until the failure list is clean.
You do not have to, and not every network needs it. If your requirement is authentication, directory integration and VLAN assignment, FreeRADIUS does that with no licence cost; the operational responsibility simply rises. If you also want a guest portal and basic profiling, PacketFence offers an open-source alternative. If your estate is predominantly Aruba, ClearPass usually generates less friction. Cisco ISE becomes the sensible answer when the access layer is largely Cisco, endpoint counts are high, and you want posture assessment, detailed profiling, guest and BYOD flows managed from one product. At the end of discovery we write down which option fits your network and why — and if another product is the right answer, that is what we will tell you.
They are handled with MAC Authentication Bypass: the switch waits a set interval for a credential and, when none arrives, submits the device MAC address to the server as its identity. But MAB is never deployed bare, because a MAC address can be spoofed in a single command. We apply two things together. Profiling verifies from behaviour that the device really is the type it claims to be, and the MAB-authorised port receives a narrow access list. A camera talks only to specific ports on the recording server; it cannot reach the internet and it cannot see other segments. So even where a spoof succeeds, what is gained is the authority of a camera.
The correct answer is EAP-TLS; the common answer is PEAP. With certificate-based authentication there is no password in play to share or phish, and when a device is lost the certificate is revoked and it is off the network the same day. The price is standing up a certificate authority and automating issuance and renewal. PEAP-MSCHAPv2 starts faster because it reuses existing directory passwords, but it carries two costs: if server certificate validation is not enforced on the client, a rogue access point can harvest credentials, and because a password is shareable the identity can be separated from the device. Where the timeline is tight we write a two-stage plan — start on PEAP, move to EAP-TLS once the certificate infrastructure exists — and we put a date on the second stage, because without one it never happens.
If it is not configured for that case, yes it does — and this is the question clients ask last rather than first. A switch that does not know what to do without a RADIUS response keeps its ports closed. The remedy is critical authentication: while the server is unreachable, ports are placed into a predefined VLAN and work continues, with sessions re-evaluated when the server returns. What that critical VLAN may reach is a separate decision; we open the minimum set of services the business needs and keep management interfaces and sensitive segments closed. We also build the server side with at least two nodes, because tying network admission to a single machine creates a larger risk than the one you set out to solve.
Yes, and in a better-behaved way. Instead of handing out a shared wireless passphrase, a guest portal is deployed: a visitor connecting lands on a splash page and either self-registers in a short form or receives a time-limited account created by a member of staff acting as sponsor. The account expires by itself. Guest traffic runs in a segment entirely separate from the corporate network with internet egress only. For businesses that provide public internet access, the record-keeping obligation is also met properly by this structure, with logs held on a dedicated collector rather than on the device itself and with clock synchronisation in place so the timeline of any incident is readable.
Through a BYOD onboarding flow. The device is redirected to a registration page on first connection, the user authenticates with their corporate identity, and the device is issued its own certificate. From that point the handset sits in the inventory bound to that person and never asks for a password again. The benefit runs both ways: the user never has to learn a shared secret, and the organisation can revoke devices individually. When someone leaves or a phone is lost, that certificate is revoked — nobody changes a wireless passphrase and nobody reconfigures hundreds of devices. We also narrow what personal devices may reach; they do not receive the same authorisation as a corporate laptop.
Our engineers hold Cisco CyberOps Associate certification and CCNA-level network training; those are individual certifications. We do not claim a corporate vendor partnership or reseller status, because we do not have one. What we do is design, deployment, phased rollout, documentation and handover. Where licensing or hardware procurement is required we run it as a separate, transparent line and point you to the vendor own channels where that is the right route. We keep the same approach in product selection: if FreeRADIUS is enough for your network, saying so is part of the job.
Related services
Design, cabling, VLAN scheme and ongoing management — the layer access control sits on.
NAC decides who gets in, segmentation decides how far they travel. The two run as a single engagement.
Where the inter-segment rule set is written: who can reach what, and which traffic is logged.
Configuration of the access layer that carries 802.1X: port settings, VLANs, routing and version-controlled configs.
Cloud-managed switching and wireless; central control of the access layer across multiple sites.
The layer that makes authentication failures, server health and the certificate calendar visible.
Remote worker and branch access; the tunnel side bound to the same identity source as NAC.
Planning the access, distribution and core layers — where the topology NAC will sit on gets drawn.
The broader programme access control belongs to: detection, response and incident investigation.
Ongoing support that owns policy maintenance, certificate renewal and authentication incidents.
The cloud-side counterpart of identity and access management, keeping one identity source consistent across both worlds.
A short discovery call to review whether your current switch fleet is ready for NAC.
Book a free 30-minute discovery call with our team.
Our network and cyber security work is carried out by a team holding internationally recognised Cisco certification.
Issued by Cisco · Holder: Devrim Tunçer
A certification covering security operations centre (SOC) competency: security monitoring, incident response and analysis of network attacks. It is the foundation we rely on for intrusion detection, log correlation and post-incident response work.
Cisco training certificate · completed January 2023
Covers networking fundamentals: routing, switching, IP addressing and network security. The knowledge base we draw on for enterprise network setup and segmentation.