We Have Antivirus and MFA — Is That Enough?

By BCyber Security Team | CISSP, CISM Last updated: 5 October 2026

If you have antivirus and MFA, you have two important controls in place — but not a complete cybersecurity posture. They reduce some common risks, yet they do not, by themselves, prove resilience, monitoring, recovery, or compliance. The more useful question is whether your controls are effective, tested, and connected to a broader risk program. In Australian terms, that usually means looking beyond tools and into evidence, governance, and operational discipline.

For BCyber, this question is not theoretical. Across our platform inventory of 23 policies, 9 processes, 50 courses, 965 published articles, 549 knowledge hub entries, 11 clients, and 14 fact-find assessments, we consistently see the same pattern: organisations often have the right tools, but not the assurance to prove those tools are working as intended. Verification note: Platform figures above are based on BCyber real platform data current at the time of publication and should be validated against your own environment, scope, and control evidence.

What does “enough” actually mean in cybersecurity?

“Enough” is not a fixed line you cross once and forget. It depends on what you are trying to achieve, who holds the risk, and what obligations apply to your organisation. If the goal is compliance, you need to show that controls exist and are working. If the goal is resilience, you need to know whether the business can keep operating after a security event. If the goal is assurance, you need evidence, not assumptions.

Antivirus and MFA each solve part of the problem. Antivirus helps identify or block some known malicious code and suspicious behaviour on endpoints. MFA makes stolen passwords much less useful, especially for remote access, email, and cloud systems. But neither control covers the whole attack surface, and neither tells you whether your environment is actually being monitored. That is where many organisations mistake presence for effectiveness. A tool on a screen is not the same as a control that is configured, reviewed, tested, and maintained.

In a layered defence model, each control is meant to compensate for the weakness of another. If a phishing email gets through, MFA may limit credential abuse. If credentials are stolen, logging may reveal unusual access patterns. If malware lands on a device, patching, hardening, and endpoint monitoring can reduce the blast radius. Security is not a single wall; it is a living forest of controls, where strength comes from how the layers grow together.

Compliance, resilience, and assurance are not the same thing

Compliance asks whether you meet an obligation. Resilience asks whether you can absorb disruption and recover. Assurance asks whether you can prove the controls are in place and functioning. These goals overlap, but they are not interchangeable. An organisation can have MFA enabled and still fail an audit question if it cannot show enforcement, coverage, or exception handling. It can have antivirus deployed and still be unprepared for a ransomware event if backups have never been restored under pressure.

For regulated Australian organisations, that distinction matters. Under APRA CPS 234, entities must maintain information security capability commensurate with vulnerabilities and threats, and must test controls regularly. The Essential Eight from the Australian Signals Directorate (ASD)/ACSC is also explicitly layered: application control, patching, MFA, backups, macro restrictions, admin privilege restriction, and more. Likewise, the Privacy Act 1988 requires “reasonable steps” to protect personal information — which is a standard that is judged by evidence and context, not intent.

The practical test is simple: would a fair reviewer believe your control story if they examined the evidence? That reviewer might be an auditor, a board member, a customer, or your own incident response lead after a breach. If the answer depends on a verbal explanation rather than logs, reports, and tested procedures, then “enough” has not yet been reached. The gap is not always technical; often it is operational.

The strongest controls are not the ones you can name quickly. They are the ones you can prove with evidence when the situation is messy.

What do antivirus and MFA do well, and where do they fall short?

Antivirus still matters, especially as a baseline layer on managed endpoints. It can detect known malware families, block suspicious executables, and alert on some obvious threats. MFA also matters, because password reuse and credential theft remain common attack paths. When MFA is enforced on email, VPN, and admin accounts, it raises the cost of account takeover. Those are meaningful gains, and they should not be dismissed.

The problem is that modern attacks rarely rely on one technique alone. Fileless malware, living-off-the-land activity, token theft, and browser-based session hijacking can all reduce the value of traditional endpoint detection or basic MFA. An attacker does not need to “break” the control if they can work around it. They may phish a user in real time, abuse a valid session, target a privileged account that is exempt from policy, or move laterally through an unpatched system. That is why control coverage matters more than control labels.

From a technical perspective, organisations should be thinking in terms of identity assurance, endpoint telemetry, and control correlation. A mature stack usually includes endpoint detection and response (EDR), centralized audit logging, conditional access policies, device compliance checks, privileged access management (PAM), and security information and event management (SIEM) correlation. Antivirus and MFA are part of that picture, but they are not the whole picture.

What antivirus helps with

Antivirus provides a basic line of defence against known malicious files and common endpoint threats. It can also create a useful alert trail when it is centrally managed and connected to response workflows. In a smaller environment, that may be the first visible sign that something is wrong. In a better-managed environment, antivirus becomes one signal among many, feeding logs into broader detection and response. Its value is real, but it is not magical.

What antivirus does not do is equally important. It does not fix software vulnerabilities, enforce least privilege, monitor cloud identity events, or restore corrupted backups. It also does not guarantee that the device is hardened against abuse of legitimate tools. If a threat actor uses PowerShell, remote admin tools, or stolen credentials, the antivirus engine may not see a clearly malicious file at all. That is why relying on it as the centre of your security program is too narrow.

What MFA helps with

MFA reduces the usefulness of a stolen password. It is especially valuable for remote access, email, and administrative portals, where password compromise can quickly become business compromise. For many organisations, enforcing MFA is one of the most sensible and immediate improvements they can make. It is also a control that auditors and customers often expect to see. In that sense, it is both practical and visible.

But MFA is not the end of identity security. Some forms can be phished, fatigue-tested, or bypassed through token theft and session replay. If a user is tricked into approving a login, the second factor can become part of the attack path. If privileged access is not separated or reviewed, MFA simply protects poor governance more efficiently. And if a cloud tenant has weak conditional access or unmanaged exceptions, the protection may be thinner than it appears on paper.

The gap between deployment and defence

The real issue is not whether you have antivirus and MFA, but whether those tools are part of a broader defensive system. A mature environment treats endpoint protection, identity controls, patching, logging, and response as connected organs of the same body. If one organ fails, another should sense the problem and respond. If nothing is watching for the next stage of attack, the first control only delays discovery. That delay can be costly, especially when ransomware, data theft, or privilege escalation is involved.

For that reason, “we have antivirus and MFA” is best understood as a starting point, not a finish line. It is the sort of statement that sounds reassuring until someone asks what happens next. What happens when a laptop is out of date, an admin account is abused, or a backup restore fails? Those are the questions that separate a tool purchase from a security posture.

Why do Australian frameworks expect more than two tools?

Australian frameworks tend to focus on governance, evidence, and control coverage rather than on a narrow list of products. APRA CPS 234 expects regulated entities to maintain information security capability proportionate to vulnerabilities and threats, and to test and report on that capability. The Essential Eight is built around layered mitigation, not a single technology. The Privacy Act 1988 and the APPs create obligations around protecting personal information with reasonable steps. None of these frameworks treat antivirus and MFA as a complete answer.

This is especially visible in sectors where BCyber routinely works with compliance-focused control environments, including financial services, healthcare, and government-adjacent organisations. For example:

• In financial services, an APRA-regulated entity may have MFA everywhere and still fail assurance if its privileged access reviews are informal, its logging is incomplete, or its backup restores are untested.
• In healthcare, a provider may protect clinician logins with MFA but still be exposed if endpoint patching lags on medical workstations or if sensitive patient records are not recoverable after ransomware.
• In government and public sector environments, the controls often need to align to Essential Eight maturity, evidence retention, and clear administrative segregation — not simply a deployed security product list.

That is because real-world assurance is broader than endpoint and identity hygiene. A customer or assessor will usually want to know whether you can identify assets, patch vulnerabilities, log and monitor activity, manage privileged access, back up critical data, train staff, and respond to incidents. They will also care whether you can demonstrate that these controls are in place, not simply that they were purchased. If you cannot show that the controls are monitored and tested, the answer is incomplete even if the software is installed.

The control areas frameworks usually expect

Most mature cyber programs include several layers that sit around antivirus and MFA. These are the controls that turn isolated tools into something defensible.

• Vulnerability and patch management for systems, applications, firmware, and network devices.
• Logging and monitoring across identity systems, endpoints, cloud services, and critical applications.
• Access governance with least privilege, joiner-mover-leaver processes, and privileged access review.
• Backups and recovery with restore testing and clear recovery objectives.
• Security awareness that helps staff recognise phishing, social engineering, and suspicious MFA prompts.
• Incident response planning with roles, contacts, escalation paths, and exercises.
• Asset and configuration management so you know what exists and how it should be secured.

These are not nice extras. They are the controls that make antivirus and MFA meaningful inside a managed security program.

At BCyber, these control themes map naturally to our ecosystem:

• GRACE Portal supports single-dashboard visibility, cross-product analytics, executive reporting, compliance tracking, and real-time monitoring.
• Paradigm helps automate governance, risk, and compliance mapping, which is especially relevant for control frameworks such as APRA CPS 234, ISO/IEC 27001, and the Essential Eight.
• Profiler is useful where human-factor risk, anomalous access, and insider threat indicators need behavioural analysis.
• CyberTriage helps compress response time with AI-powered triage and incident playbooks, which is critical when a security event needs immediate containment.
• Perfect Storm helps teams validate resilience assumptions by simulating compound threat scenarios, including ransomware plus identity compromise.
• Privacy in Depth is relevant where Australian privacy obligations drive control selection and evidence requirements.
• TopSpin supports forecasting and capacity planning, which can matter for log retention, backup growth, and security data lifecycle decisions.

BCyber’s training catalogue also supports capability uplift through courses aligned to common control gaps, including coverage for awareness, governance, and operational response. Where useful, these can be mapped to broader program maturity across GRACE pillars: visibility, governance, monitoring, response, and resilience.

Evidence is the point, not the decoration

Frameworks and assessors do not only care that controls exist. They care whether you can demonstrate implementation through reports, logs, test results, and decisions. That may include backup restoration records, MFA enforcement reports, patch compliance dashboards, incident exercise notes, or privileged access review sign-offs. The question is no longer “Do you have the control?” but “Can you prove it works in practice?” That shift matters because paper compliance often collapses during an actual incident.

If your organisation wants to align to Australian expectations, think in terms of traceable evidence. What logs are retained, who reviews them, how often backups are restored, and who approves exceptions? Who owns the control, who measures it, and who is accountable when it drifts? Those are the questions that reveal whether security is part of business operations or simply attached to them.

Which controls close the biggest gaps around antivirus and MFA?

The best place to start is usually with the controls that reduce the most common failure modes. That means patching, logging, access governance, recovery, training, and response. These are the controls that often determine whether a security event becomes a minor disturbance or a major disruption. They also help answer the practical question behind every assurance conversation: what happens when the first layer fails?

Vulnerability and patch management

Unpatched systems remain one of the easiest ways into an environment, especially when internet-facing services or legacy applications are involved. Good patch management starts with visibility, because you cannot fix what you cannot see. Once assets are known, updates need to be prioritised based on exposure and impact, not on convenience. Critical vulnerabilities on public systems should not wait in the same queue as low-risk desktop updates.

Patch management also includes firmware, network appliances, third-party software, and cloud service configurations. Many organisations focus on laptops and servers, then leave edge devices or niche business applications outside the patch rhythm. That is where gaps form quietly. A healthy program sets service levels for remediation, tracks exceptions, and reports overdue items in a way leadership can actually understand.

Logging, monitoring, and alerting

Logging is what turns a security event into something visible. Without it, a compromise can sit unnoticed until the business impact becomes obvious. Identity logs, endpoint events, cloud audit trails, and application logs all help build a more complete picture. Alerting should cover suspicious logins, privilege changes, malware detections, and unusual data movement. The aim is not to collect everything forever; it is to retain the right evidence long enough to investigate.

Monitoring becomes especially important when MFA is in place, because attacks often shift from password theft to session abuse or admin misuse. If your logs cannot show who accessed what, when, and from where, then MFA only partially answers the risk. A strong logging design also supports incident response, forensic review, and post-event improvement. In other words, logs are not just technical artefacts; they are part of the organisation’s memory.

Access governance and privileged access

Least privilege is one of those ideas that sounds obvious until it is tested against real admin sprawl. Many environments accumulate access that no longer matches role, need, or ownership. People change jobs, leave teams, or retain emergency access long after a project ends. Joiner-mover-leaver discipline, privileged account separation, and regular access reviews are the controls that keep this under control.

A separate admin account for privileged tasks reduces the chance that day-to-day use becomes high-risk use. Limiting who can approve access and requiring review of exceptions also creates a better audit trail. These measures are not about bureaucracy for its own sake. They are about preventing a single compromised account from becoming a broad organisational problem.

BCyber’s Profiler platform aligns particularly well here, because behavioural risk scoring and access pattern monitoring can help identify suspicious privilege use, shared account issues, and human-factor anomalies before they become incidents.

Backups and recovery

Backups are only useful if they restore. Many organisations discover this only when the pressure is already high. Immutable or offline backups reduce the chance that attackers can encrypt or delete the recovery copy. But even good backups need regular restore testing, because untested recovery is a hope, not a capability. Recovery planning should define realistic time and data loss expectations, then test them.

Ransomware is often the event that exposes whether recovery has been treated as a design requirement or an afterthought. If critical systems cannot be restored in a predictable way, then the organisation is relying on the absence of an incident rather than on resilience. That is a risky assumption. Recovery capability should be treated as seriously as prevention, because it may be the difference between interruption and survival.

Awareness and incident response

People remain part of both the problem and the defence. Phishing simulations, short targeted training, and clear reporting paths can improve the chance that staff notice suspicious requests before they become incidents. But awareness alone is not enough. Staff also need a simple process for escalating concerns, especially when the message involves MFA prompts, bank details, or urgent password resets. Confused people make predictable mistakes; prepared people create friction for attackers.

Incident response is the other half of that discipline. A documented plan should explain who does what, when to involve legal or executive stakeholders, and how to preserve evidence. Tabletop exercises are useful because they expose the gaps that policies hide. The point is not to produce a perfect document. The point is to make sure the organisation can think and act under pressure.

BCyber’s CyberTriage is relevant here because response speed matters. The difference between 4-minute triage and delayed manual analysis can materially change containment outcomes in ransomware, BEC, or token-compromise scenarios.

How do you know whether your controls are actually working?

The short answer is that you measure, test, and review them regularly. If a control has never been tested, it is often being assumed rather than assured. That does not mean every test has to be expensive or complex. It does mean the organisation should be able to answer basic questions about coverage, quality, and response. Proof is what turns a security claim into a believable one.

A good starting point is to ask whether the control reaches the whole environment or only the easy parts. Are all endpoints covered by antivirus or endpoint protection? Is MFA enforced for every user, or only for selected systems? Are patches applied within a defined time frame, or are exceptions piling up? Are logs retained, reviewed, and correlated, or simply stored somewhere in case someone asks? These are not rhetorical questions; they are practical tests of control maturity.

Useful evidence to review

• Antivirus or endpoint protection deployment coverage.
• MFA enforcement across email, VPN, cloud, and administrative access.
• Patch compliance reports for critical and high-risk vulnerabilities.
• Log retention periods and review procedures.
• Backup success and restore test records.
• Incident response exercise outcomes.
• Access review sign-offs for privileged accounts.
• Security awareness participation and phishing reporting trends.

This evidence does not need to be perfect to be useful. In fact, it is better when it is honest about what is still being improved. If something is incomplete, note it as TBD or as a tracked gap rather than pretending it is done. That kind of transparency is one reason evidence-led programs build trust faster than brochure-level security stories. A living security program should be able to name its strengths and its unfinished work.

A practical self-check

Ask yourself whether the business would notice if antivirus silently stopped reporting, if MFA exceptions multiplied, or if backup restores had never been validated. Ask whether leadership receives a picture of control health or merely a quarterly reassurance. Ask whether your current provider can show evidence from logs, tests, and exercises rather than only platform dashboards. If those questions are difficult to answer, the issue is probably not a missing tool. The issue is the absence of operational visibility.

What should you do next if you only have antivirus and MFA today?

If antivirus and MFA are your main controls, the next step is to build around them rather than replace them. Start with the failure points that would hurt most if they were exploited tomorrow. That usually means patching, backup recovery, logging, and privileged access. These are not glamorous tasks, but they are the difference between a partial setup and a defensible security program.

A sensible near-term sequence is to confirm that your current controls are actually enforced. Then check whether you can detect misuse, recover data, and respond to an incident without improvising. From there, you can turn your attention to governance, training, and assessment. Security maturity grows best when the roots are deepened before the canopy is expanded.

A practical 30-day focus

1. Confirm endpoint protection coverage across all managed devices.
2. Enforce MFA on email, remote access, and administrative accounts.
3. Inventory critical systems, accounts, and data stores.
4. Review patch backlogs, especially internet-facing and high-risk assets.
5. Test at least one critical backup restore.
6. Check whether logs are being retained and reviewed.
7. Validate who approves privileged access and exceptions.

These actions will not solve every problem, but they will quickly reveal where the biggest gaps sit. They also create useful evidence for conversations with leadership, auditors, or service providers. If a control cannot be confirmed in a matter of days, that is worth knowing early. The value is not just in fixing issues, but in learning where the organisation is more fragile than it assumed.

A practical medium-term focus

Once the basics are clear, move into the controls that make the program sustainable. That includes centralised logging, privileged access review, incident response planning, phishing resilience, and regular evidence collection. It also means assigning ownership for each control so that improvement does not depend on memory or goodwill. Security programs drift when no one is responsible for watching the drift.

Over time, many organisations benefit from mapping controls to a recognised framework such as the Essential Eight, ISO/IEC 27001, or relevant APRA and privacy obligations. That mapping helps leadership see what is covered, what is missing, and what remains untested. It also turns cyber from an abstract concern into a managed set of decisions. The goal is not to collect frameworks; it is to create a structure that compounds learning across the organisation.

BCyber clients commonly use combinations of these frameworks in practice, especially:

• APRA CPS 234 for regulated financial services,
• Essential Eight for baseline maturity and prioritisation,
• ISO/IEC 27001 for ISMS structure and auditability,
• Privacy Act 1988 / APPs for personal information protection obligations,
• and in some environments, sector-specific contractual security requirements and government assurance checks.

Conclusion

Antivirus and MFA are necessary, but they are not enough on their own. They reduce real risks, yet they do not cover patching, logging, privileged access, recovery, training, or incident response. Australian compliance and assurance expectations also ask for evidence that controls are monitored and tested, not just installed. That is why the better question is not whether you have the tools, but whether the whole control environment can be shown to work.

If you want a practical way to think about your posture, use this lens: coverage, evidence, and recovery. Coverage asks whether the right controls reach the right assets. Evidence asks whether you can prove those controls are operating. Recovery asks whether the business can continue when something fails. When all three are visible, security becomes a program rather than a guess.

Key Takeaways

• Antivirus and MFA are baseline controls, not a complete program.
• Most Australian frameworks expect broader coverage, including patching, logging, access governance, backups, and incident response.
• Evidence matters as much as deployment, because controls must be shown to work.
• A tested backup, monitored identity stack, and clear response plan often matter more than another tool purchase.
• If your security strategy stops at antivirus and MFA, you have a start — not a finish.

Sources and further reading

Authoritative references used in this article:

• APRA CPS 234 — Information Security: https://www.apra.gov.au/cps-234-information-security
• ACSC Essential Eight: https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight
• ACSC Information Security Manual (ISM): https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism
• NIST Cybersecurity Framework 2.0: https://www.nist.gov/cyberframework
• NIST SP 800-53 Rev. 5: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
• ISO/IEC 27001 overview: https://www.iso.org/standard/27001
• OAIC Australian Privacy Principles: https://www.oaic.gov.au/privacy/australian-privacy-principles

BCyber recognition

• 2025 Finalist Cybersecurity Professional of the Year — Karen Stephens, Co-Founder & CEO
• 2025 GRC Provider of the Year — Finalist
• 2025 AI Innovator - Cyber Security — Finalist

Potential bias/conflict note: This article references BCyber products and services because it is published by BCyber. Product examples are included to illustrate how control evidence, monitoring, and governance can be operationalized; readers should validate suitability against their own environment, regulatory obligations, and independent advice.