If you’ve spent any time hardening network devices, chances are you’ve come across the Message of the Day — or MOTD banner. It’s one of those things that’s dead easy to overlook, because on the surface it feels trivial. A bit of text on a screen. A box to tick. Move on.

But here’s the thing — if you’re working in regulated environments, studying for your CCIE, or just trying to build solid habits from the ground up, getting your banners right genuinely matters. More than most people give it credit for.

In this post I’m going to walk you through why MOTD banners matter from both a security and legal standpoint, what the CIS Cisco IOS Benchmark actually says about them, and how to configure one properly on a Cisco IOS device. I’ll also share the banner template I use personally, which is aligned with UK legal frameworks.

Why Does a Banner Actually Matter?

I’ll be straight with you — for a long time I treated MOTD banners as a chore. Something you slapped on a device to keep an auditor happy and thought nothing more of. I’d SSH into a lab switch and be greeted with a cheerful Welcome! message, or worse, a default Cisco banner with the hostname and IOS version plastered all over it — basically handing anyone doing reconnaissance a head start.

It wasn’t until I started working in more regulated environments that it clicked. An MOTD banner actually does two important jobs:

Legal Standing — In the UK, the Computer Misuse Act 1990 is the relevant legislation here. For that act to carry weight, users need to have been clearly warned that unauthorised access is an offence. No warning banner? You could theoretically be undermining any future prosecution before it even gets started, simply because there was no explicit notice that access was restricted. That’s not a position you want to be in.

Compliance Alignment — Frameworks like the CIS Cisco IOS Benchmarks and NCSC guidance both flag banners as a baseline security control. Miss it or word it poorly, and it’ll come up as a finding in an audit. It’s one of those things that’s embarrassing to get pulled up on because it’s so easy to get right.

I like to think of it as a “No Trespassing” sign. It won’t stop a determined attacker — nothing will on its own — but it removes any ambiguity about whether access is permitted, and it puts you in a much stronger position legally if something does go wrong.

What Does the CIS Benchmark Say?

The CIS Cisco IOS 15 Benchmark (and its IOS 16/17 equivalents) covers banners under the Access, Authentication and Authorisation section. The headline points are:

• A login warning banner must be configured, appearing before any authentication prompt.
• The banner must not contain anything that aids reconnaissance — no hostnames, no IOS version strings, no organisation names within the banner text itself.
• The banner should make clear that the system is monitored, that access is restricted to authorised users, and that activity may be logged and audited.

Something that trips people up — and it caught me out early on — is that IOS has multiple banner types, and they’re not all the same:

For compliance, banner motd is your primary control. That said, combining it with banner login is considered best practice — it ensures the warning is front and centre regardless of how the session is established.

What to Include (and What to Avoid)

Before getting into the config, here’s a quick sanity-check list:

Include:

• A clear statement that the system is restricted to authorised users only
• Notice that all activity is monitored and may be recorded
• A reference to the Computer Misuse Act 1990 (for UK deployments)
• A statement that by proceeding, the user is consenting to monitoring

Avoid:

• Hostname or device name
• IOS version or platform type
• Organisation name or location details
• Anything that sounds welcoming — words like “Welcome” imply open access, which is the opposite of what you want

The reason for stripping out device details is straightforward: why help an attacker profile your environment before they’ve even had to authenticate?

The Configuration

Right, here’s the actual config. The ^C character acts as the delimiter — it marks where the banner starts and ends. You can use any character that doesn’t appear in the banner body itself; ^C is just the convention most folk go with.

banner motd ^C
*******************************************************************************
*                                                                             *
*         RESTRICTED SYSTEM - AUTHORISED ACCESS ONLY                          *
*                                                                             *
*  Access is restricted to authorised personnel only.                         *
*                                                                             *
*  Unauthorised access to this system is a criminal offence under the         *
*  Computer Misuse Act 1990 and may result in prosecution.                    *
*                                                                             *
*  All activity on this system is monitored and recorded. By proceeding,      *
*  you consent to such monitoring. Evidence of unauthorised use may be        *
*  disclosed to law enforcement authorities.                                  *
*                                                                             *
*  If you are not an authorised user, disconnect immediately.                 *
*                                                                             *
*******************************************************************************
^C
banner login ^C
*******************************************************************************
*              Enter your credentials to proceed.                             *
*******************************************************************************
^C

Verifying the Configuration

Once you’ve pushed the config, verify it with:

show banner motd
show running-config | section banner

Best way to actually test it is to close your SSH session and reconnect — the banner should appear before the Username: prompt. If it does, you’re good.

A Note on CCIE Relevance

If you’re studying for CCIE Enterprise Infrastructure (which I am), banners aren’t going to show up as a dedicated lab task. But understanding why controls exist and how they map to real-world frameworks is part of what separates a well-rounded engineer from someone who’s just memorised the command syntax.

On a more practical note — if you’re spinning up lab topologies in CML, I’d encourage you to get into the habit of including proper banners from the start. It might feel unnecessary in a lab environment, but normalising the pattern means it becomes second nature when you’re working in production.

Wrapping Up

A CIS-aligned MOTD banner takes five minutes to configure. It’s not the most glamorous part of device hardening, but it’s one of those controls that quietly signals to auditors — and to yourself — that you’re taking security seriously. It covers your legal bases, satisfies compliance requirements, and stops you accidentally advertising your device details to anyone who happens to be scanning your management plane.

If you’ve got thoughts on how you approach banners in your own environment, or there are other CIS benchmark controls you’d like to see covered, stick a comment below — I’m always keen to hear how others are tackling this stuff.

Until next time — keep hardening, keep studying. 🛠️

References:

• CIS Cisco IOS Benchmarks
• Computer Misuse Act 1990
• NCSC Device Security Guidance