When a new organization becomes a managed client, the first weeks are not spent on exciting projects. They are spent applying one security baseline. It is the same baseline for every client we manage, whether they have eight people or eight hundred, and I designed it to be boring on purpose.
In this article I will walk through what that baseline contains, the order we apply it in, and why I think one standard applied to everyone protects you far better than a custom configuration negotiated client by client.
Why one standard beats a custom setup for everyone
Most security gaps I find in a new environment are not exotic. They are exceptions that made sense at the time. The owner who did not want a second sign-in step. The old accounting server that needed an open port. The vendor who was given admin rights for a weekend project three years ago. Each one is a small hole that someone has to remember, and nobody does.
A single baseline changes that in a few practical ways:
- Technicians know what to expect. When every environment is configured the same way, the person answering your ticket does not have to rediscover your setup first.
- Alerts mean the same thing everywhere. A risky sign-in warning or a device that falls out of compliance is handled the same way for every client, so nothing is quietly ignored because it is normal here.
- Fixes roll out once. When a new threat appears, we change the standard and apply it to everyone, instead of working out which clients happen to be exposed.
- Reporting is honest. We report against the same standard every month, so you can see exactly where you meet it and where you do not.
What the baseline contains
Multi-factor authentication on every account, admins first
MFA is required for every user, with no exemptions for executives. Administrator accounts get the strongest methods available, such as security keys, passkeys or an authenticator app with number matching. Text message codes are not acceptable for anyone with admin rights.
The one deliberate exception is a pair of emergency access accounts, sometimes called break-glass accounts. They exist so you cannot be locked out of your own environment if MFA or a sign-in policy fails. They have long random passwords, are stored securely, are excluded from normal policies, and any sign-in on them raises an alert.
Conditional access
MFA answers the question of who you are. Conditional access answers whether this sign-in should be allowed at all. Our baseline policies block legacy authentication protocols that cannot do MFA, require a managed and compliant device to reach company data, ask for MFA again when a sign-in looks risky, and restrict admin sign-ins to trusted conditions. Location rules are used carefully, because people travel and a badly written country block causes more tickets than it prevents.
Encrypted, managed devices
Every laptop and desktop is enrolled in device management and has full-disk encryption turned on, with the recovery keys stored centrally rather than on a sticky note or in one technician's notes. The result is simple: a laptop left in a taxi becomes a hardware loss, not a data breach. Managed devices also let us confirm that the firewall, antivirus and screen lock are on, rather than assuming they are.
A patching cadence you can state out loud
Patching works when it follows a written cadence. Operating system updates go to a small pilot group first, then to everyone within a defined window. Browsers, PDF readers, meeting apps and other third-party software are patched too, because attackers do not care which vendor wrote the vulnerable code. Firewalls, switches and wireless equipment get firmware updates on a schedule. Critical vulnerabilities that are being actively exploited skip the queue.
The test I use is whether you can say your patching policy in one sentence and then see a report proving it happened.
Email protections
Email is still where most attacks start. The baseline publishes SPF, DKIM and DMARC records for every domain you own and moves DMARC towards enforcement, so others cannot easily send mail pretending to be you. Inbound mail is scanned for malicious attachments and links, messages from outside the organization are clearly tagged, and staff have a simple way to report anything suspicious.
Least privilege
Nobody browses the web or reads email with an administrator account. Admins have a separate account for admin work. Staff do not have local admin rights on their laptops, and software installs go through an approved process instead. Access is reviewed when someone changes roles or leaves, so permissions do not quietly pile up over the years. Vendors get named, time-limited access rather than a shared password that never expires.
Logging that someone reads
Sign-in logs, admin audit logs, endpoint detection events and firewall logs are kept for longer than the default retention, and the important events are routed to people as alerts. Logs that are only opened after an incident are better than nothing, but the real value is noticing the impossible sign-in or the disabled antivirus while it is happening.
What happens when someone asks for an exception
Requests for exceptions are normal, and I would rather hear them than have people work around the rules. The usual ones sound like this: the front desk shares one account, a director does not want MFA on their phone, a software vendor insists on permanent admin access.
Our approach is to find the real need and solve it inside the standard. A shared account becomes a shared mailbox with individual sign-ins. A director who dislikes phone prompts gets a hardware security key. A vendor gets access that is switched on when they need it and switched off afterwards. In the rare case where a genuine exception is unavoidable, it is written down, approved by the business owner, given compensating controls, and reviewed on a set date. An undocumented exception is just a vulnerability with a story attached.
What day one actually looks like
We do not switch everything on at once. The order matters, because it puts the biggest risk reduction first and avoids locking people out.
- Discovery. List every account, every admin role, every device and every domain. You cannot protect what you have not found.
- Admin cleanup and MFA. Remove unused admin rights, set up emergency access accounts and require strong MFA for admins, then for everyone.
- Conditional access in report-only mode. Policies run in observation first so we can see who would be blocked before anyone is.
- Device enrolment and encryption. Devices are brought under management and encrypted, then compliance is enforced.
- Email authentication and filtering. DNS records are published and tightened gradually as legitimate senders are confirmed.
- Patching rings and logging. The cadence is set, alerting is connected, and the first monthly report establishes the starting point.
Staff hear about each change before it happens, with plain instructions. Most of the friction people expect from security comes from surprises, not from the controls themselves.
Questions to ask your current provider
- Is MFA enforced for every account, including admins and executives, and which methods are allowed?
- How many exceptions to your security standard exist in our environment, and who approved them?
- Where are our device encryption recovery keys stored?
- What is our patching cadence, and can I see last month's compliance?
- Who receives alerts for risky sign-ins, and what happens next?
If the answers are vague, the baseline probably is too.
How we apply this at Ceifa
Every client on our managed IT services starts on the same security baseline, and our monthly reporting shows where you stand against it. For organizations that want deeper protection, such as threat detection and response, our managed security services build on that same foundation rather than replacing it. If you would like to know how your current setup compares, talk to us and we will walk through it with you.
Frequently asked questions
Will MFA everywhere slow my staff down?
Very little, when it is set up well. With managed devices and sensible conditional access, people are usually prompted when something changes, such as a new device or an unusual location, rather than every time they open an app.
What if we have a system that cannot support MFA?
We isolate it. That can mean restricting it to the internal network, putting it behind a gateway that does support MFA, or limiting who can reach it. We also document it as an exception with a plan to replace or upgrade it.
Is a security baseline enough on its own?
It is the foundation, not the whole building. A baseline removes the most common ways in. Monitoring, threat detection, backups you have tested and staff awareness are what protect you when something gets past it.
Why not tailor the security setup to each organization?
Your business processes are unique, but the ways attackers get in are not. We tailor how the baseline fits your work, such as which apps and devices are approved, while keeping the controls themselves the same for everyone.