17 Common Security Misconfigurations UK SMEs Should Check
Security problems in small businesses are often much less exotic than the headlines suggest.
A surprising amount of risk comes from ordinary things being configured badly: an administrator account without MFA, software that has stopped receiving updates, an unnecessary service exposed to the internet, excessive permissions, or logs nobody is looking at.
None of the issues below guarantees that a business will be compromised. Equally, fixing one of them does not make an organisation “secure”.
They are simply practical things I would expect to look at when reviewing an SME environment.
The priority should always depend on what is exposed, what an attacker could realistically do with it, and what matters to the business.
1. Multi-factor authentication is missing from important accounts
Passwords are routinely stolen through phishing, credential reuse and breaches of unrelated services.
MFA makes possession of a password alone insufficient to access an account.
For most SMEs, I would prioritise:
- Microsoft 365 or Google Workspace
- Cloud administration
- Remote access
- Financial systems
- Password managers
- Privileged administrator accounts
- Systems containing sensitive customer information
Where available, phishing-resistant authentication such as passkeys or FIDO2 security keys can provide stronger protection than codes delivered by SMS.
What to check
Confirm which systems support MFA, whether it is actually enforced, which users are excluded and whether privileged accounts receive stronger protection.
2. Administrator privileges are too widely distributed
Administrative access should be exceptional rather than normal.
If users operate day-to-day with elevated privileges, a compromised account or malicious process gains considerably more capability.
This applies to:
- Local administrator rights
- Microsoft 365 roles
- Azure and AWS permissions
- Application administration
- Network equipment
- Security tools
- Backup platforms
What to check
Identify who has privileged access, why they need it, when it was last reviewed and whether separate administrative accounts are used where appropriate.
Avoid permanent privilege where temporary or just-in-time access will do.
3. Software is no longer supported
A fully patched product can still be insecure if the vendor has stopped providing security updates.
Unsupported operating systems, applications, network appliances and mobile devices deserve particular attention because newly discovered vulnerabilities may never be fixed.
What to check
Maintain an inventory containing at least:
- Product
- Version
- Owner
- Business purpose
- Support status
- Replacement date where necessary
End-of-life technology should be replaced, isolated or otherwise risk-treated rather than silently remaining in production.
4. Security updates are not managed consistently
Patching is easy to describe and surprisingly difficult to do consistently.
Problems typically arise because organisations do not know what they own, do not know who is responsible, or cannot determine whether updates actually installed.
What to check
A useful patch-management process should cover:
- Operating systems
- Applications
- Browsers
- Mobile devices
- Network appliances
- Firmware
- Cloud-hosted workloads
It should also define responsibility, expected timescales, exception handling and how compliance is verified.
See my guide to security update management for more detail.
5. Microsoft 365 security settings have never been reviewed
Microsoft 365 can become a substantial part of an SME’s security boundary.
Identity, email, file sharing, Teams, SharePoint, Power Platform and administrative access can all contain settings that deserve review.
Common issues include:
- Weak MFA enforcement
- Excessive administrator roles
- Inappropriate external sharing
- Legacy or unnecessary authentication paths
- Weak application consent controls
- Excessive guest access
- Inadequate auditing
- Poorly configured email authentication
What to check
Do not assume that because Microsoft operates the platform, your tenant is securely configured for your particular organisation.
Review identity, administrative access, external sharing, mail security, audit settings and security tooling as a coherent whole.
6. Internet-facing services are exposed unnecessarily
An open network port is not automatically a vulnerability.
The relevant question is what service is listening behind it, whether it needs to be publicly accessible and whether that service is securely maintained.
Exposing RDP, SSH, database services, management consoles or obsolete protocols directly to the internet can create unnecessary attack surface.
What to check
Regularly enumerate your public-facing services and ask:
- Does this need to be exposed?
- Who owns it?
- Is authentication appropriate?
- Is MFA available?
- Is the software supported and patched?
- Can access be restricted by network, VPN or identity?
If nobody knows why something is publicly reachable, investigate it.
7. Default or unnecessary services remain enabled
Technology is often shipped with features designed to maximise compatibility and ease of deployment.
Those features are not always required in production.
Examples include:
- Default accounts
- Unused services
- Unnecessary protocols
- Sample applications
- Administrative interfaces
- Unused integrations
- Permissive sharing settings
What to check
Establish secure configuration baselines for the technology you actually use.
Useful starting points include vendor security guidance and, where appropriate, recognised configuration benchmarks.
Read more about secure configuration.
8. Password controls encourage poor behaviour
Password security is not improved simply by requiring more punctuation.
Common problems include:
- Short passwords
- Predictable password rules
- Password reuse
- Periodic forced changes without evidence of compromise
- Shared administrator passwords
- Credentials stored in documents or spreadsheets
What to check
Encourage long, unique passwords and provide a password manager where appropriate.
Prevent known compromised or commonly used passwords where the platform supports this.
Do not rely on password strength alone for important accounts; use MFA.
9. External sharing is too permissive
Cloud collaboration makes it very easy to share information outside the organisation.
That is useful, but settings can accumulate over time.
Look particularly at:
- SharePoint
- OneDrive
- Teams
- Google Drive
- Dropbox
- Project-management platforms
- CRM systems
What to check
Determine whether anonymous sharing is allowed, how guest access is managed, whether external access expires and who can create new sharing links.
Do not assume old external access disappears by itself.
10. Logging exists, but nobody could investigate an incident with it
Many organisations technically have logs without having useful security visibility.
Logs might be disabled, retained for too short a period, scattered across services or never reviewed.
What to check
At minimum, consider logging for:
- Authentication
- Administrator actions
- Endpoint security
- Email security
- Cloud administration
- Important applications
- Remote access
- Firewall and network security devices
The goal is not “log everything forever”.
The goal is to retain enough useful information to identify suspicious behaviour and understand what happened if an incident occurs.
11. Backups are accessible through the same credentials as production
Having backups is not the same as having recoverable backups.
If an attacker compromising an administrator account can also delete or encrypt the backup estate, the backup provides considerably less protection.
What to check
Consider:
- Separate administrative credentials
- MFA
- Immutable or offline copies where appropriate
- Retention periods
- Monitoring of backup failures
- Restoration testing
The important question is not whether the backup job says successful.
It is whether you can actually restore the systems and data the business needs.
12. Cloud permissions are broader than necessary
Cloud IAM environments can accumulate permissions very quickly.
Users, roles, workloads and service identities may gain access that is no longer required.
What to check
Review:
- Privileged roles
- Stale accounts
- Unused permissions
- Cross-account access
- Service principals
- Access keys
- Role assumptions
- Inherited permissions
Pay particular attention to identities that can modify IAM itself.
13. Secrets are stored in code, configuration files or scripts
API keys, database passwords, tokens and certificates frequently end up somewhere they should not.
Common locations include:
- Source-code repositories
- Deployment scripts
- Configuration files
- CI/CD variables
- Shared documents
- Developer laptops
What to check
Use appropriate secret-management facilities and ensure credentials can be rotated.
If a secret has been committed to a repository, simply deleting the current copy may not remove it from history.
Treat exposed credentials as compromised and rotate them.
14. APIs do not enforce authorisation properly
An API can authenticate a user correctly and still expose information they should not be able to access.
Common weaknesses include:
- Broken object-level authorisation
- Excessive data returned to callers
- Insufficient rate limiting
- Weak authentication
- Poor validation
- Unnecessary administrative functions
What to check
Test whether one authenticated user can access another user’s objects merely by changing an identifier.
Apply authentication and authorisation at the API rather than relying solely on the client application.
Regular technical testing is particularly useful for business-critical APIs.
15. Security groups and firewall rules are too broad
Rules such as 0.0.0.0/0 are sometimes necessary.
They are also sometimes the cloud equivalent of “I couldn’t make it work, so I opened everything”.
What to check
Look for:
- Unrestricted inbound management access
- Broad outbound rules
- Obsolete firewall rules
- Duplicate rules
- Temporary exceptions that became permanent
- Security groups with unclear owners
Network controls should reflect the connectivity actually required.
16. Former staff, contractors and old devices retain access
Access tends to accumulate much more efficiently than it disappears.
An employee leaving the organisation may have access across identity systems, SaaS products, VPNs, source-code repositories, cloud platforms and locally managed applications.
What to check
Joiner, mover and leaver processes should deal with more than the main user account.
Review:
- SaaS applications
- Cloud IAM
- VPN
- Physical access
- Shared credentials
- API keys
- Service accounts
- Company-owned devices
Periodically review dormant accounts even where no employee has formally left.
17. Nobody owns the configuration
This is perhaps the most important one.
A security problem that has no owner usually remains a security problem.
Organisations frequently know that something needs fixing but cannot answer:
- Who owns the system?
- Who can approve the change?
- Who is responsible for patching it?
- Who accepts the residual risk?
- Who checks the fix worked?
What to check
Important systems should have identifiable technical and business owners.
Security findings should have named remediation owners and target dates rather than living indefinitely in a spreadsheet.
Which security misconfigurations should you fix first?
Do not blindly rank the list above from 1 to 17.
Context matters.
A sensible prioritisation considers:
| Factor | Lower concern | Higher concern |
|---|---|---|
| Exposure | Restricted or internal | Internet-facing |
| Exploitability | Difficult prerequisites | Easy or actively exploited |
| Privilege | Low privilege | Administrative access |
| Data | Little sensitive data | Sensitive or regulated data |
| Business impact | Minor inconvenience | Material operational or financial impact |
| Attack path | Isolated issue | Enables access to more important systems |
A relatively ordinary weakness can become important when several of those factors combine.
For example:
internet exposure → vulnerable service → stolen credential → excessive cloud permission → sensitive data
That is often a more useful way to think about risk than simply counting “critical” findings from a scanner.
What about Cyber Essentials?
Cyber Essentials is not itself a security configuration.
It is a UK government-backed certification scheme covering five technical control areas:
- Firewalls
- Secure configuration
- Security update management
- User access control
- Malware protection
For many SMEs it provides a useful baseline for dealing with several of the weaknesses described above.
If certification is relevant to you, see my Cyber Essentials guidance.
What about DLP, CASB and security products?
You may have noticed that I have not included “no CASB”, “no DLP platform” or lack of a particular security product as misconfigurations.
That is deliberate.
A business can have perfectly reasonable security without buying every category of security technology.
A DLP platform may be extremely valuable where sensitive information needs sophisticated monitoring and control.
A CASB or equivalent capability may make sense in a complex cloud or SaaS estate.
Neither should be deployed simply because somebody put MISSING CASB = HIGH RISK in a checklist.
Start with the risk and the requirement, then decide whether a product solves it.
A practical SME security checklist
If you only have limited time, I would start by establishing whether:
- MFA is enforced on important accounts
- Privileged access is controlled
- Software is supported and patched
- Microsoft 365 or Google Workspace has been reviewed
- Unnecessary internet-facing services are removed
- Backups are protected and tested
- Cloud permissions are understood
- Logs would support an investigation
- Old accounts and access are removed
- Important systems have clear owners
That will not solve every security problem.
It will, however, give you a considerably better picture of whether basic configuration weaknesses are creating unnecessary risk.
When an independent security review helps
An external review can be useful if:
- Nobody has reviewed the environment end-to-end
- Responsibility is split between several internal teams and suppliers
- Your MSP manages most technology but nobody independently reviews security
- Customers are asking increasingly detailed security questions
- You are preparing for Cyber Essentials or ISO 27001
- Cloud environments have grown faster than security governance
- Vulnerability tools generate more findings than the team can reasonably prioritise
The useful outcome should not be another enormous list of things labelled URGENT.
It should be a clear view of what matters, why it matters and what should happen next.
Need help reviewing your security configuration?
I provide practical security architecture, risk, Cyber Essentials, ISO 27001 and technical assurance support for UK organisations.
If you need an independent view of your environment, the aim is not to make every possible issue sound catastrophic. It is to identify the weaknesses that could realistically hurt the business and work out what is worth fixing first.
