Why your cyber hygiene looks fine on paper but still fails under attack  

When an attack doesn’t require the resources of a nation-state because the fundamental prerequisites are absent, there’s no need to use expensive zero-day exploits.

For example, if an exposed appliance has a known vulnerability, the administrator has excessive privileges, or an old service account is still functional, then spending on a zero-day is unnecessary.  

So why does cyber hygiene that looks fine on paper still fail under attack?

Because a control that’s configured isn’t necessarily a control that works. Policies and dashboards can tell you a control has been set up. They can’t tell you whether it will stop an attacker. And weaknesses that each look low risk can combine into a path to sensitive information.  

The aim is not to make compromise impossible since no reasonable security program could make such a promise; rather it is to eliminate simple avenues, restrict those who do manage to get in, detect them quickly, and retain the capacity to recover.  

Five simple questions will indicate where to focus.  

What might an attacker notice that you have forgotten?  

The systems nobody thinks they own. Forgotten development environments, old VPN gateways, abandoned cloud resources, and applications that still authenticate against production identity platforms may provide exactly the foothold an attacker needs.  

The evidence comes to the same conclusion.

According to Verizon’s 2026 Data Breach Investigations Report, exploitation of vulnerabilities had become the main method of initial access in the breaches it examined, making up 31% of those in its report dataset, and at the same time third-party involvement had increased considerably.

The NCSC has also identified exploitation of vulnerabilities in older systems as a factor contributing to serious cyber incidents.  

You can’t secure assets you don’t know exist, so keep a reliable inventory covering endpoints, servers, cloud resources, SaaS applications, domains, certificates, repositories, service accounts, and externally accessible systems.  

First, order them according to the degree of active exploitation, exposure, and severity. It is becoming more and more difficult to justify carrying out monthly patching for critical vulnerabilities that are accessible over the internet.

For instance, CISA suggests that the Known Exploited Vulnerabilities catalog should be used as a basis when prioritising vulnerabilities. A vulnerability that is being actively exploited in an internet-facing VPN concentrator should be handled differently from one that has the same score on an isolated internal system.

Decide in advance what constitutes emergency patching: who is authorised to approve an emergency change, what testing is necessary, and how quickly a critical vulnerability can realistically be fixed. 

What does a stolen identity unlock?  

How far could that identity go?

In cloud-first environments identity has in effect become part of the perimeter, so it is worthwhile to regularly pose this simple question: if that identity were compromised, what could an attacker access?  

Wherever it is practical, enforce phishing-resistant multi-factor authentication, especially when it comes to administrators and important systems.

Where possible, centralise authentication using single sign-on and make use of conditional access to apply additional controls according to the user, device, location, and level of risk. Ensure that administrative identities are separated from regular accounts and that they are closely monitored.

The same level of attention should be given to service accounts and machine identities: they frequently remain in use long after the applications for which they were originally created and might have privileges that no one would be willing to grant nowadays.  

Passwords aren’t the only type of credential that needs to be taken into account. API keys, OAuth tokens, application secrets, signing keys, and certificates can grant powerful access and thus bypass the controls that are designed for interactive users. They should be stored in vaults or on secrets-management platforms, not in source code, scripts, configuration files, or spreadsheets.

Owners should be assigned together with expiry dates, automatic rotation should be arranged where the platform permits it, and an inventory should be kept. If no one knows where a compromised secret is being used, it will not be possible to revoke it quickly.  

Configuration can also drift. The secure configuration that is in place when a system is deployed may become less secure as administrators add integrations, permissions, exceptions, and new services.

To set baselines, enforce them using policy, infrastructure-as-code and automated guardrails, and investigate any exceptions, it is necessary to refer to CIS benchmarks and the relevant NIST guidance, particularly in the case of externally shared data, OAuth applications, public cloud storage, administrative roles and conditional-access exclusions.   

What happens after they’re in?  

That depends on what you built for the day preventative controls fail. Strong cyber hygiene assumes they will, occasionally, and limits what follows.  

Arrange the different environments so that a breach of one system does not automatically grant access to all the other systems. Limit access to administrative interfaces and management networks, reduce unnecessary connectivity between systems in the same network, and eliminate any permanent privileges whenever this is possible.

Consider backups to be an integral part of the security structure by keeping protected or immutable copies, restricting administrative access to them and regularly testing the restoration process. The NCSC’s advice to organisation leaders is nowadays more concerned with business continuity.

If the organisation’s IT systems become unavailable, how will it continue to operate? The organisation should have an answer to this question before an incident takes place.  

Collecting logs isn’t the same as monitoring. Centralize security-relevant telemetry from identity providers, endpoints, cloud platforms, SaaS applications, network infrastructure, and critical systems, and retain it long enough to investigate an attacker who may have stayed undetected for weeks or months.

Detection should focus on behavior, not just malware. Examples include:  

• Unexpected privilege escalation  
• Suspicious OAuth application consent  
• MFA manipulation or repeated authentication prompts  
• Creation of fresh credentials or persistence mechanisms  
• Accounts that were previously not in use are now becoming active.  

Since attackers are increasingly employing genuine tools and valid credentials, detection methods must be able to identify abnormal activity even in the absence of a malicious executable.   

Who else holds the keys?  

Your suppliers and, as is now the case, your own AI services also possess more trust than you have deliberately allowed.  

The example of the SolarWinds supply chain breach in 2020 demonstrates that by compromising a single trusted supplier, attackers can gain access to a large number of organizations, a lesson which is still relevant.

You should identify any suppliers who have privileged access, hold sensitive information or have critical operational dependencies. Find out how they authenticate, what resources they can access, and how quickly you can remove that access.

Supplier assurance must not be limited to questionnaires; where the risk is significant enough to warrant it, you should request evidence of their security controls, independent testing, incident-response capabilities and secure development practices.

The aim is not to eliminate supply-chain risk but to understand where that risk is most concentrated and avoid giving suppliers more trust than is necessary.  

AI is altering the speed and the economics of cyber operations, even though the current evidence shows that attackers are mainly improving existing techniques rather than replacing them.

According to the NCSC, groups associated with China, Russia, Iran and North Korea are employing large language models for the purposes of reconnaissance, social engineering, processing information that has been stolen, vulnerability research and the development of exploits.

This highlights the importance of fundamental measures which are difficult to automate: strong authentication, limited privileges, secure configurations, rapid patching, good telemetry and effective incident response.  

You should also consider the use of AI within your own organization. AI services that have not been approved, autonomous agents, and various integrations can introduce new flows of corporate information and new access tokens into environments which security teams may not have fully understood yet. Nowadays, cyber hygiene must include AI services as well as traditional SaaS.  

How do you know any of it works?  

You should test it under realistic conditions; although policies and dashboards can inform you that a control has been set up, it is only through testing that you can determine whether it will prevent an attacker.  

Is it actually possible to use stolen credentials on an unmanaged device? Can an attacker circumvent multi-factor authentication by means of an authentication route that has been neglected? Can a compromised SaaS account gain access to sensitive information? Can a normal endpoint reach administrative infrastructure? Does suspicious activity trigger an alert, and will anyone look into it?  

Traditional penetration testing gives you a valuable snapshot of risk, but contemporary environments change constantly.

New SaaS integrations appear and cloud permissions change. Employees create API tokens and suppliers receive access. Conditional-access exceptions are added during troubleshooting and sometimes remain long after the initial issue disappears. The attack surface that existed during an annual penetration test may be materially different several months later.  

Continuous offensive security testing provides you with a better means of verifying your defensive assumptions. It can do this by simulating realistic attacker behaviour, such as credential compromise, abuse of SaaS services, cloud misconfiguration, privilege escalation, and lateral movement, thus revealing areas where security hygiene has deteriorated and where seemingly effective controls can be bypassed.  

It can also examine how individual weaknesses combine, something that vulnerability scanners are unable to do. An exposed credential may appear to be of low risk, just as an overly permissive SaaS role or an inadequately segmented cloud workload might.

Together, however, they could form an attack path to sensitive information. 

Cyber hygiene represents a strategic capability.  

Good cyber hygiene is cumulative in nature: it should make it harder to achieve an initial compromise, restrict the extent to which a compromised identity can go, make it more difficult to persist, increase the chances of detection, protect the systems needed for recovery, and then continue to test those assumptions.  

As the NCSC observed in its 2025 assessment, much current threat activity is an evolution of standard techniques rather than an entirely new form of cyber-attack. That matters because many required defensive measures are already understood.

The challenge for IT and security leaders is execution: applying them consistently across increasingly multifaceted environments and continuously verifying that they stay effective.   

Put your cyber hygiene to the test.  

At CovertSwarm we carry out continuous offensive security testing in order to demonstrate how well your controls work when facing realistic attacker behaviour.

Our approach does not simply involve verifying that patching, identity, cloud, and SaaS controls are documented or turned on; we check whether they actually prevent an attacker from gaining access, raising their privileges, moving around your environment, and getting to important systems or information.  

To find out where your cyber hygiene could fail under real-world attack conditions, talk to CovertSwarm.