Make Your Network Hack-Proof.

Phishing-resistant MFA and identity protection

Imagine a cybercriminal has obtained an employee's password. They may have bought it from a criminal marketplace, discovered it in an old data breach, stolen it through a fake website or persuaded someone to type it into a fraudulent sign-in screen. With password-only authentication, that secret may be enough to open the door. Multi-factor authentication (MFA) is intended to make a stolen password insufficient.

But here's the part that deserves special attention in 2026: not every form of MFA resists phishing. A criminal can sometimes convince a user to read out a text-message code, approve repeated push prompts or enter a time-based one-time code into a fake login page. Adversary-in-the-middle phishing services may relay those codes in real time and try to capture a usable session. A basic MFA checkbox is therefore not the finish line.

FIDO2/WebAuthn security keys and properly implemented passkeys use cryptography bound to the legitimate service. They are designed to stop a fraudulent site from obtaining an authenticator response it can reuse at the real site. Syncable passkeys can be a good practical choice for ordinary employees when the ecosystem is appropriately secured; for highly privileged administrators, consider device-bound hardware security keys and stronger recovery procedures. No authenticator eliminates all risk: compromised endpoints, stolen active sessions and malicious app permissions still deserve protection.

How to put it into practice

• Make a list of every identity provider, email system, VPN, remote management console, domain administrator, backup administrator, financial platform and cloud application that could touch sensitive systems or data.
• Protect the most powerful accounts first. Register more than one approved authenticator where appropriate, then close weaker fallback routes that would let an attacker simply bypass the new protection.
• Roll out phishing-resistant sign-in to the wider business in waves. Give employees straightforward instructions and a tested support process for lost, damaged or replaced authenticators.
• Use conditional access to consider device compliance, unusual sign-in behavior and the sensitivity of the requested resource. Reduce the number of accounts permitted to perform privileged tasks.
• Secure account recovery. Verify identity before help-desk resets, audit changes to MFA methods and alert on unexpected new authenticators or privileged-role assignments.
• Protect nonhuman identities as well. Service accounts, application tokens, certificates and workload identities require limited permissions, secure storage and lifecycle ownership; they cannot simply enroll a security key and be forgotten.

Consider a familiar scenario: someone calls pretending to be the CFO and says they've lost their phone and need MFA removed before a critical payment deadline. Even if the voice sounds convincing, the help desk should follow its independent identity-verification procedure. The identity recovery process can become the very hole that defeats excellent MFA.

Zero Trust principles

There was a time when the network edge was treated almost like the fence around a factory. Outside the fence was suspicious; inside the fence was trusted. Cybercriminals learned to appreciate that arrangement. Compromise one workstation, steal one VPN account or get access through one supplier, and the next systems might be reachable with little additional resistance.

Zero Trust changes the starting assumption. A request should not be trusted simply because it came from the office, a corporate laptop or a familiar IP address. Access is evaluated according to the identity making the request, the device being used, the resource requested, the permissions needed and relevant risk signals. NIST's Zero Trust Architecture guidance describes this shift from trusting a network location to protecting the actual resources.

Zero Trust is not one software package, and it does not mean showing a login prompt every time a user clicks a button. Good implementations combine strong authentication, sensible authorization, device health, limited session scope, network controls and monitoring. The rules should be as unobtrusive as possible for legitimate work and far less forgiving when circumstances change.

Start with the most valuable systems

• Identify the business resources that would cause the greatest harm if stolen or disabled: payroll, customer information, finance, domain identity, backups, source code and core business applications.
• Map who actually needs access, from which managed devices and for which purpose. Remove excessive permissions, old accounts and shared administrative access.
• Separate workstations from sensitive server groups and separate administrative paths from everyday application traffic. Microsegmentation is one possible technique; thoughtful firewall and identity policies can also make a significant improvement.
• Replace broad, permanent access with resource-specific, time-limited access where practical. Evaluate whether a VPN connection grants far more network access than the user needs.
• Continuously monitor relevant changes in authentication, device posture and access behavior. Use well-defined exceptions for legacy systems while planning to eliminate unnecessary exceptions.
• Test whether a compromised ordinary employee identity can reach unrelated databases, domain administration or the backup repository. Document and correct the paths that should never have existed.

Suppose a salesperson's laptop is infected. That is a serious problem. But the sales identity should not have direct administrative access to the accounting SQL server, and that laptop should not be able to talk to domain controllers on any port it chooses. The outcome depends on specific controls, not on whether a product brochure says “Zero Trust.”

Modern endpoint detection and response

Traditional antivirus still plays a useful role, but today's attacks do not always arrive as a recognizable executable file. A criminal who steals administrator credentials may use perfectly legitimate utilities, remote-management software, PowerShell, scripts, scheduled tasks or operating-system features to carry out malicious work. These are often called living-off-the-land techniques because the attacker uses tools that are already there.

Endpoint Detection and Response (EDR) adds visibility into endpoint behavior, helps analysts investigate suspicious activity and can provide containment and remediation actions. Extended Detection and Response (XDR) attempts to connect relevant signals across endpoints and additional sources, such as identity, email, cloud and networking. Products differ substantially: neither label alone guarantees a complete detection capability.

For example, a file server beginning to encrypt thousands of files could be an emergency. So could a newly elevated administrator account, unexpected security-tool tampering or a workstation reaching unfamiliar destinations immediately after suspicious script execution. An alert is only useful if it reaches somebody who can understand and act on it.

Build detection around an actual response

• Deploy compatible EDR agents to supported employee computers, servers and other important endpoints, accounting for operational technology and systems that cannot safely accept ordinary agents.
• Protect the agent and its configuration from unauthorized tampering. Make alerts and inventory visible even when users are away from the office.
• Define the specific high-severity conditions that require prompt attention: suspected ransomware, widespread malware, confirmed credential abuse, disabled protection, unexpected privileged actions and unauthorized remote access.
• Decide who is monitoring alerts on nights, weekends and holidays. If internal staff cannot cover this, evaluate a managed detection and response (MDR) service and understand precisely what the contract includes.
• Pre-authorize safe containment actions, such as network isolation for an ordinary workstation, and document situations when automatic isolation could interrupt critical operations.
• Forward useful endpoint, identity and security events to a protected location; set log retention based on investigative requirements, cost and applicable obligations.
• Test the complete chain: detection, triage, contacting the owner, containment, evidence preservation, recovery and closing the incident. Use approved benign simulations or vendor-provided tests.

Security operations can go wrong in two directions. Too few alerts allow an intruder to remain unnoticed; too many meaningless alerts train the team to ignore everything. Review recurring false positives, changes to the environment and real-world incidents to keep the detection rules effective.

Ransomware-resilient backups

If a cybercriminal compromises a business administrator's account, a perfectly ordinary online backup share may become another target. The attacker may try to delete snapshots, encrypt backup files, compromise the backup administrator, alter retention settings or simply wait until good recovery points have aged out. A green “Backup Successful” message does not mean the business can survive that situation.

Offline and immutable backups are designed to make those attacks much harder. An offline copy cannot be modified over the network while disconnected. A properly implemented immutable backup restricts alteration or deletion for a defined retention period. The distinction matters: not every product using the word immutable prevents an attacker with control over its administration, storage account or lifecycle settings from undermining recoverability.

The traditional 3-2-1 idea — multiple copies, more than one storage medium or failure domain, and an offsite copy — is a useful starting point, not a full design. What matters is that the business has appropriate isolation, independent access controls, protected retention and working restores. One cloud account containing both production and every backup may not provide meaningful separation if the same compromised administrator controls them all.

Build the recovery design before the emergency

• List the services the business cannot operate without. Include identity systems, databases, file stores, financial platforms, virtual machines, configuration files, SaaS information, certificates and keys needed to decrypt backups.
• Agree on a Recovery Point Objective (RPO) — how much recent data loss the business can tolerate — and a Recovery Time Objective (RTO) — how long critical services can reasonably be unavailable.
• Use more than one independent recovery copy where risk warrants it. Protect at least one from the credentials and systems used in everyday operations, through tested offline storage or suitable immutable retention.
• Secure the backup management plane with named administrative identities, phishing-resistant MFA where supported, limited roles, protected logging and alerts when backup jobs, deletion attempts or retention settings change.
• Keep a safe record of backup architecture, restoration dependencies, license details and recovery secrets. Make certain that the people restoring the business can reach them when the primary network is unavailable.
• Test individual restores regularly, and schedule full recovery exercises for critical services. Verify not only that files return, but that databases are consistent, applications open, permissions remain correct and users can resume essential work.
• Plan to restore into a clean, isolated environment if an incident occurs. Reintroducing compromised systems or malicious persistence can restart the problem.

Ransomware operators may steal information before encrypting it. Backups are essential for availability, but they do not erase stolen data or remove potential notification and legal obligations. That is why DLP, access restrictions, monitoring and incident response still matter.

Incident response plans and exercises

At 8:17 on a Tuesday morning, an employee calls and says their files suddenly have strange extensions. Another employee has an identical problem. Someone finds a ransom note. Who has the authority to disconnect a machine? Who calls the business owner? Should IT shut down all servers? Where are the backup credentials? Who is going to preserve the evidence?

These questions are much easier to answer when the situation is hypothetical. An incident response plan spells out the roles, communications and decision-making needed to contain a threat and bring the business back into safe operation. It should be practical enough that somebody can use it under pressure, and protected enough that an attacker cannot quietly alter or delete the only copy.

The plan should not be written only for ransomware. Include compromised email accounts, stolen administrator credentials, cloud data exposure, lost devices, supplier compromise, malicious remote support, denial of service and operational outages that may initially look like attacks.

Write down the decisions before they are urgent

• Define who can declare an incident, what triggers escalation and which people have authority to isolate hosts, disable accounts, block Internet access or authorize a business interruption.
• Maintain a current contact list for management, internal IT, MSSP/MDR, cloud and telecom providers, insurers, legal counsel, public relations and any outside incident-response firm. Keep an offline or otherwise independent copy.
• Prepare short playbooks for ransomware, suspected data exfiltration, account takeover and vendor remote-access abuse. Each should include immediate safety steps, evidence preservation, communication and the recovery decision process.
• Keep reliable logs, clocks, system inventories and incident notes. Before wiping or rebuilding compromised systems, consult the response lead about evidence needed for analysis or legal obligations.
• Plan alternative communications. If the business email or chat platform is compromised, use a preapproved independent way to reach responders and leadership.
• Determine how to assess notification and reporting obligations. These vary by jurisdiction, industry, contract and the facts of the incident; involve appropriate legal and regulatory specialists.
• Decide in advance who may speak publicly, notify customers, contact law enforcement or communicate with an extortionist. A ransom payment is not a guarantee of decryption or nondisclosure and may carry legal and operational risks.

Then practice. In a tabletop exercise, participants walk through a realistic scenario and make the decisions they would make during an actual incident. Let someone introduce complications: the CFO is traveling, the backup administrator is unavailable, your normal communications system is down or the suspected supplier cannot be reached. These are not reasons to panic; they are exactly the gaps exercises are supposed to uncover.

After each exercise or real incident, assign owners and deadlines to corrective actions. A tabletop that ends with a stack of notes but no changes may provide confidence without providing better security.

Cloud and SaaS security

Your business may own an excellent firewall and still have a major cybersecurity problem if someone shares a payroll spreadsheet with the wrong person from a cloud drive. In modern environments, information moves through email, document collaboration, customer relationship management, finance applications, cloud storage, identity services and application integrations — often without crossing your office router.

Cloud services generally operate under a shared responsibility model. The provider secures important parts of its infrastructure, but customers frequently remain responsible for accounts, configurations, access, data protection, third-party integrations and monitoring. The exact division differs among SaaS, managed platforms and infrastructure services.

Microsoft 365, Google Workspace and other major SaaS platforms offer many strong protections, but their defaults, license-level features, outside sharing settings and logging capabilities are not all identical. Configuration needs review, not assumption.

Secure the cloud your employees actually use

• Inventory cloud tenants and business applications, including tools created by departments without formal IT purchasing approval. Record the owner, sensitivity of stored data, authentication method and vendor-support contact.
• Require strong identities and MFA, with phishing-resistant methods for sensitive accounts. Minimize standing administrative roles and review privileged access and emergency accounts separately.
• Review sharing permissions, public links, guest accounts, external collaboration, document downloads and retention. Use labels or data classification so sensitive information receives stronger treatment.
• Inspect application permissions, OAuth consent grants, automation tokens, API integrations and service principals. A seemingly innocent app may gain more access than an employee realized.
• Configure mail-domain protections such as SPF, DKIM and DMARC where applicable, along with anti-impersonation, malicious-link and attachment policies appropriate to the service.
• Enable and retain useful audit logs, alerts for unusual sign-ins, account recovery changes, risky administrative actions and large-scale sharing or downloads. Route important detections to a monitored response team.
• Protect data in cloud storage with access management, independent recovery capabilities where needed, and explicit retention/deletion policies. Syncing files is not automatically the same as a recoverable backup.
• For IaaS/PaaS systems, also examine publicly reachable storage, network security groups, exposed secrets, infrastructure code, identity roles and encryption-key management. A cloud security posture management (CSPM) tool may assist but does not substitute for ownership of findings.

One useful exercise is to attempt a permitted test share of a document classified as confidential to an external personal email address. Is the action blocked, approved, logged or invisible? The result tells you more about real-world data protection than the presence of a cloud-security logo on a dashboard.

Supply-chain and third-party risk

Suppose you have excellent security controls, but an outside payroll consultant keeps a permanent administrator account in your environment. Or the manufacturer of a trusted remote-management tool distributes a compromised software update. Those are very different kinds of supply-chain risk, and both deserve a place in your cybersecurity program.

Security depends partly on suppliers, contractors, software developers, cloud providers, business partners and managed service providers. But it would be misleading to say that your security is only as strong as the single weakest vendor. The damage a supplier can cause depends on its access, the information it holds, its own safeguards and the limits you enforce around the relationship.

Treat high-impact vendors differently from low-impact vendors

• Maintain a list of material vendors and what they can access: customer records, payment details, cloud administration, source code, network connectivity, backups or production systems.
• Rank them by potential damage and business dependency. A provider with unrestricted management access warrants deeper review than an office-supply company with no technical connection.
• Ask high-impact suppliers about MFA, patch management, privileged access, incident notification, encryption, subprocessors, backup resilience and independent security assessments. Review relevant SOC 2 reports or other evidence where provided; a report is not a universal security guarantee.
• Contract for reasonable security expectations: protection of shared data, incident-notification procedures, acceptable subcontracting, data return/deletion, access revocation and support during investigations, with legal review as needed.
• Give vendor accounts the minimum permissions required. Favor named, monitored, time-limited access and require approval before particularly sensitive remote administration.
• Track your software components and dependencies. Software bills of materials (SBOMs), software composition analysis, signed releases and a maintained patching process can improve visibility, but an SBOM alone does not prove software is secure.
• Prepare for a supplier failure or compromise. Know which credentials, integration keys and network routes to revoke, and how the business can keep operating without that supplier temporarily.

The supply-chain question I would ask is simple: if this vendor were compromised tonight, what could the attacker do in my business tomorrow morning? That answer should determine both the level of vendor due diligence and the technical limits around the connection.

Ongoing security awareness

The first time employees learn about a new attack should not be while they are trying to recover from it. Criminals change their stories frequently. They impersonate trusted vendors, deliver convincing payment requests, place malicious QR codes in unexpected locations, send fake shared-document invitations and sometimes pretend to be the company's own technical support team.

People remain an essential part of defense, but security awareness should not turn employees into scapegoats. Most people are hired to perform a business job, not to analyze every email header or defend themselves from professional criminals without assistance. They need practical examples, safe defaults, strong sign-in tools and an easy way to ask for help.

Frequent, short, role-relevant training can be more useful than a single annual lecture. It should be paired with meaningful technical controls. Training alone cannot compensate for weak authentication, uncontrolled administrative privileges or the absence of endpoint protection.

Make awareness part of ordinary operations

• Teach everyone a small set of reliable behaviors: stop on an unexpected request, verify through a known independent channel, avoid entering codes on unfamiliar websites, report suspicious messages and never allow unsolicited remote support.
• Train people differently according to their work. Accounting needs payment-change verification; help-desk staff need strong identity-reset procedures; executives need impersonation and travel-awareness examples; developers need secure secrets and dependency practices.
• Use realistic, authorized exercises covering phishing, fraudulent sharing invitations, QR-code lures, repeated MFA approvals, help-desk impersonation and urgent vendor-bank-detail changes.
• When a person reports a suspicious message, acknowledge the report and explain what happened. Make the process simple enough that employees will actually use it.
• Use a non-punitive approach for good-faith reporting. A simulation should identify gaps in awareness or workflow, not create public embarrassment or a reason to hide a mistake.
• Include new employees, managers, contractors and departing employees in training and access-lifecycle processes; update the examples as the real threat environment changes.

A particularly effective control for finance is an independent callback to an already verified number for changes to payment instructions. A polished email, a familiar signature or even a convincing voice recording should not be enough to redirect money. That procedure protects the employee as much as the business.

AI-related threats and defenses

Artificial intelligence adds an unusual cybersecurity challenge: it changes both what criminals can do and what legitimate businesses can automate. AI tools can help defenders analyze alerts, summarize large amounts of information and accelerate routine tasks. They can also help attackers draft believable fraudulent messages, translate convincing scams into more languages, impersonate voices and generate variations of malicious content. The old rule that a poorly written email must be fraudulent was never reliable; in 2026 it is an especially poor guide.

There is another side to this. Employees may paste confidential contracts, customer information, source code, security logs or passwords into an AI service without understanding how that service stores, processes or shares the material. The business may then be exposed through its own convenience tools.

And applications that give an AI assistant access to email, files, websites, code repositories or business systems face a distinct risk known as prompt injection. An attacker-controlled document or web page can contain instructions aimed at the AI assistant rather than at the employee reading the document. If the assistant treats untrusted content as authority and has excessive permissions, it may disclose information or take actions that the user never intended.

Adopt AI with clear boundaries

• Publish an approved-use policy. Identify permitted services, approved accounts, data classifications and the circumstances in which confidential or regulated business information must not be entered.
• Review provider terms, retention, human-review arrangements, enterprise controls and integration permissions before authorizing business use. A subscription tier or a privacy promise should be evaluated rather than assumed to satisfy every requirement.
• Require independent verification of unusual instructions received by email, chat, telephone or video, especially requests involving money, passwords, security exceptions and account recovery. A known callback procedure is more useful than trying to decide if a voice “sounds real.”
• Give AI-connected applications the least access they can function with. Avoid broad administrator tokens, unrestricted file access and unattended authority to make payments, delete information or change permissions.
• Require a human approval step before high-impact actions. Treat content from websites, messages, retrieved documents and external tools as untrusted input, even when the assistant presents it confidently.
• Log high-risk automated actions, test against prompt injection and accidental data leakage, and review AI-related workflows whenever the underlying service, connector or model changes.
• Use AI-generated security findings as leads to verify, not as undisputed facts. A convincing explanation is not the same as evidence of compromise.

Imagine asking an AI assistant to summarize a supplier's document. Hidden inside the document is an instruction telling the assistant to send the business's contact directory somewhere else. The correct design ensures the document is merely data, and that the assistant lacks the authority to transmit the directory without an appropriately authorized, explicit action.

Align your cybersecurity work with modern frameworks

Security work can become an endless set of urgent tickets. Another router needs an update. Another phishing test must run. Another supplier wants remote access. Without a framework, it becomes difficult to show leadership what is improving, what remains exposed or why one project should be funded before another.

NIST Cybersecurity Framework (CSF) 2.0 offers a useful way to organize the work around six functions: Govern, Identify, Protect, Detect, Respond and Recover. The Govern function helps put ownership, risk decisions and supply-chain responsibility where they belong. The other five functions describe the continuing operational cycle of understanding assets, reducing threats, finding problems, responding and restoring business capabilities.

The CIS Critical Security Controls v8.1 offer a more prescriptive set of safeguards. CIS Implementation Group 1 is a reasonable starting point for many organizations with limited resources; larger or more complex organizations may need additional safeguards. Standards and frameworks support each other, but they are not interchangeable certifications.

For regulated or contractual requirements, use the specific standards that actually apply. A SOC 2 examination, for example, concerns a service organization's controls under a defined scope and period; adopting NIST CSF does not automatically produce a SOC 2 report. CMMC requirements are relevant to applicable U.S. Department of Defense contracts, not every business that uses a computer. Legal and compliance specialists should determine obligations based on facts and contracts.

Turn a framework into a business plan

• Govern: Identify the executive risk owner, accountable technical teams, business priorities, approved risk appetite, security policies and supplier expectations.
• Identify: Build an inventory of devices, software, people, privileged identities, critical data, cloud systems and dependencies. You cannot reliably protect assets you do not know exist.
• Protect: Prioritize phishing-resistant MFA, secure configurations, patching, encryption, restricted access, awareness and segmentation.
• Detect: Implement useful monitoring across endpoints, identity, cloud and critical networks, with a clear route from signal to investigation.
• Respond: Maintain incident plans, authorities, communications, evidence handling and realistic exercises.
• Recover: Maintain independent backups, tested restoration, business continuity arrangements and lessons learned.

Next, create a simple current-state and target-state assessment. For every important gap, record its likely impact, the proposed safeguard, who owns it, the resources needed, the planned date and how completion will be verified. This turns “we should improve cybersecurity” into work the organization can fund and measure.

For a smaller business, a practical first 90 days could focus on identifying critical assets and administrators, removing exposed remote management, securing email with phishing-resistant MFA, fixing known-exploited vulnerabilities, protecting backups and rehearsing an incident response call. A second period can improve segmentation, detection, vendor controls and secure configuration. The exact priority should always follow the organization's own risks.