How to Configure Port Security on a Cisco Switch (Step by Step)
Port security is the first line of defense against rogue devices on an access port — someone plugging in an unauthorized laptop, or worse, a cheap unmanaged hub to fan a single port out to several hosts. It works by capping how many source MAC addresses a port will accept and deciding what happens when that limit is exceeded. Here's the full configuration on Cisco IOS: lock the port down, learn the legitimate MAC(s), pick a violation action, and confirm it's actually enforcing.
Part of the Device Security & SSH learning hub
Step 1 — Set the port to static access and enable port security
Port security requires the port's mode be explicitly set — access or trunk — before it will attach; it rejects the command while the port is still negotiating trunk state via dynamic auto/desirable (IOS returns "command rejected: ... is a dynamic port"). It's a common myth that port security only works on access ports — Cisco IOS also supports it on a static trunk, with independent per-VLAN limits via switchport port-security maximum <n> vlan <vlan-list>. This guide covers the more common case: a static access port for a single PC or a PC behind an IP phone. Lock the mode down first, then turn the feature on.
At this point the port is protected but not yet limited to anything meaningful — the default maximum is 1 MAC address with no addresses learned, so the next host to talk on the wire becomes the allowed one. You still need to size the limit and decide how MACs get learned.
SW1(config)# interface gi0/1
SW1(config-if)# switchport mode access
SW1(config-if)# switchport port-securityStep 2 — Set the MAC limit and enable sticky learning
The maximum sets how many source MAC addresses the port will accept at once. Use 1 for a single PC, or 2 for a PC behind an IP phone (data + voice each need their own entry). Set it too low and a legitimate second device trips a violation the moment it shows up.
Sticky learning has the port learn whatever MAC(s) it sees first and add them to the running config as static secure entries — no manual MAC entry required. That also means they're only permanent if you save the config; a reload without a copy to startup-config throws the learned addresses away and the port has to relearn them.
SW1(config-if)# switchport port-security maximum 2
SW1(config-if)# switchport port-security mac-address stickyStep 3 — Choose a violation action and verify
The violation action decides what happens when an unauthorized MAC shows up. The default, shutdown, err-disables the entire port — traffic stops completely until you manually recover it. restrict drops the offending frames, logs the event, and increments a violation counter, but keeps the port up. protect does the same drop silently, with no log and no counter — useful for suppressing noise, but it hides the fact that something happened, so restrict is usually the better default for a lab or a monitored access layer.
Confirm the mode, the limit, and which MACs actually got learned before you call it done. Once the right MACs are learned, save with copy running-config startup-config so the sticky entries AND the violation action survive a reload.
This is the kind of config that looks right in isolation but only proves itself when you plug in a second device and watch the violation counter move — which is exactly the gap a real IOS lab with a graded answer key closes.
SW1(config-if)# switchport port-security violation restrict
SW1(config-if)# end
SW1# show port-security interface gi0/1
SW1# show port-security address
SW1# copy running-config startup-configCommon problems (and the fix)
switchport port-security is rejected on the interface — the port's mode was never nailed down, so it's still negotiating as a dynamic auto/desirable port. Set the mode explicitly first: switchport mode access for the single-PC or PC-behind-phone scenario in this guide (or switchport mode trunk if you're securing a trunk with per-VLAN limits) — then port security attaches.
The port goes err-disabled the moment a second device plugs in — you left the default violation shutdown in place. That's not a bug, it's the strictest setting; if you want the port to keep passing traffic for the allowed hosts while blocking the extra one, use violation restrict instead. If you do want shutdown's behavior, recover the port by going into its interface config and cycling shutdown, then no shutdown (or configure errdisable recovery cause psecure-violation on the switch so it clears on its own after a timeout).
Sticky MACs disappear after a reload — they were learned into running-config but never saved. Copy running-config to startup-config after the port has learned its addresses.
A phone-and-PC port keeps tripping violations — the maximum is set to 1 but there are two MACs on the wire (the IP phone and the PC behind it). Raise the maximum to 2, or if the port also runs switchport voice vlan, cap each VLAN independently with switchport port-security maximum <n> vlan access and switchport port-security maximum <n> vlan voice instead of sharing one combined limit.
Frequently asked questions
My switch port shut itself down after a port security violation — how do I bring it back?
The default violation mode is shutdown, which drops the port into err-disabled state, and it stays down until you manually bounce it with 'shutdown' then 'no shutdown' on the interface. To recover automatically, enable 'errdisable recovery cause psecure-violation' and set 'errdisable recovery interval <seconds>', but fix the offending device first or the port will just trip again. Use 'show interfaces status err-disabled' to confirm port security was the cause.
Do sticky MAC addresses survive a reboot?
Sticky learning writes the learned MACs into the running-config, but the running-config is not saved automatically, so a reload wipes them and the port relearns whatever happens to be plugged in at boot. Run 'copy running-config startup-config' after the legitimate devices are connected to make the entries permanent. Sticky only converts dynamically learned addresses into config lines — it does not by itself persist them across a power cycle.
What's the actual difference between protect, restrict, and shutdown?
All three block traffic from MACs beyond the limit, but shutdown err-disables the whole port (the default and most aggressive), while protect and restrict leave the port up and just drop the offending frames. The difference between the two milder modes is visibility: restrict increments the violation counter and sends a log/SNMP trap, whereas protect drops silently with no counter or notification. Choose restrict when you want a record of the event, protect when you don't need one.
Why does port security block my PC when there's an IP phone on the same port?
An IP phone with a PC daisy-chained behind it presents at least two source MACs — the phone's and the PC's — so a 'maximum 1' setting will register a violation. Raise the limit, commonly 'switchport port-security maximum 2' (or 3), to allow for the phone plus the attached workstation. On platforms using a voice VLAN the phone's MAC is counted in that VLAN, so check 'show port-security interface' to see the real address count.
Should I use port security or 802.1X for access control?
Port security is a static, MAC-based control that is fast to deploy, but it doesn't authenticate the user and a determined attacker can spoof an already-allowed MAC. 802.1X authenticates the device or user against a RADIUS server before the port forwards traffic, giving much stronger identity-based control at the cost of more infrastructure. A common approach is port security on simple access ports and 802.1X where real authentication is required, and the two can also be layered together.
Practice this on graded Cisco labs
Reading is step one — build Device Security & SSH on real Cisco IOS and grade your own config, or try a free sample lab first.