---
title: 10 technical errors that leave the door open to cybercriminals (and how to avoid them)
description: Discover 10 technical errors that can expose your organization to cybercriminals and learn how to mitigate them effectively. Secure your systems today.
image: https://blog.cyberoo.com/hubfs/Cyberoo%20Blog%20-%20Grafiche%20di%20copertina%20(4)-Nov-05-2026-08-54-55-7241-AM.gif
---

<https://blog.cyberoo.com/en/10-errori-tecnici-che-aprono-la-porta-ai-cybercriminali-e-come-evitarli#menu>

- Solutions
  
  Cyber Security Suite
  
    - [What is the Cyber Security Suite?](https://cyberoo.com/en/cyber-security-suite/)
    - [Cypeer – Internal Security](https://cyberoo.com/en/cypeer-managed-detection-and-response/)
    - [CSI – Cyber Threat Intelligence](https://cyberoo.com/en/cyber-threat-intelligence/)

  Cybersecurity Advisory
  
    - [Incident response](https://cyberoo.com/en/incident-response/)
    - [Risk Assessment](https://cyberoo.com/en/risk-assessment/)
    - [VA/PT](https://cyberoo.com/en/vulnerability-assessment-penetration-test/)
    - [Cyber Security Advisory & VCISO](https://cyberoo.com/en/cyber-security-advisory-vciso/)

  Titaan Suite
  
    - [Titaan Neemesi – GDPR compliance](https://cyberoo.com/en/titaan-neemesi-gdpr-compliance/)

  Security Awareness 
  
    - [KEATRIX – Human Risk & Security Training Platform for Business](https://cyberoo.com/en/keatrix-security-awareness-platform-business/)
- Corporate
  
  Cyberoo
  
    - [Company](https://cyberoo.com/en/cybersecurity-company/)
    - [Certifications](https://cyberoo.com/en/certifications/)
    - [People](https://cyberoo.com/en/people-in-cybersecurity/)
    - [Above The Rest](https://cyberoo.com/en/above-the-rest/)
    - [Jobs](https://cyberoo.com/en/jobs/)

  Investors
  
    - [Investors relations](https://cyberoo.com/en/investors-relations/)
    - [Sustainability](https://cyberoo.com/en/sustainability/)
- Resources
  
    - [Cyber Blog](https://blog.cyberoo.com/en)
    - [Tech Blog](https://cert.cyberoo.com/en/)
    - [Press News](https://cyberoo.com/en/news-press/)
    - [Media Kit](https://cyberoo.com/en/media-kit/)

[![Cyberoo](https://blog.cyberoo.com/hubfs/raw_assets/public/Cyberoo_May2023/images/CYBEROO-logo.svg)](https://cyberoo.com/en/)

- [Contacts](https://cyberoo.com/contacts/)
- [English](https://blog.cyberoo.com/en) 
    - [Italiano](https://blog.cyberoo.com/)
    - [Français](https://cyberoo.com/fr/)
    - [Deutsch](https://cyberoo.com/de/)
    - [Polski](https://blog.cyberoo.com/pl)
    - [Español](https://cyberoo.com/es/)

<https://blog.cyberoo.com/en/10-errori-tecnici-che-aprono-la-porta-ai-cybercriminali-e-come-evitarli#sidewidgetarea>

- Solutions 
    - Cyber Security Suite 
          - [What is the Cyber Security Suite?](https://cyberoo.com/en/cyber-security-suite/)
          - [Cypeer – Internal Security](https://cyberoo.com/en/cypeer-managed-detection-and-response/)
          - [CSI – Cyber Threat Intelligence](https://cyberoo.com/en/cyber-threat-intelligence/)
    - Cybersecurity Advisory 
          - [Incident response](https://cyberoo.com/en/incident-response/)
          - [Risk Assessment](https://cyberoo.com/en/risk-assessment/)
          - [VA/PT](https://cyberoo.com/en/vulnerability-assessment-penetration-test/)
          - [Cyber Security Advisory & VCISO](https://cyberoo.com/en/cyber-security-advisory-vciso/)
    - Titaan Suite 
          - [Titaan Neemesi – GDPR compliance](https://cyberoo.com/en/titaan-neemesi-gdpr-compliance/)
    - Security Awareness 
          - [KEATRIX – Human Risk & Security Training Platform for Business](https://cyberoo.com/en/keatrix-security-awareness-platform-business/)
- Corporate 
    - Cyberoo 
          - [Company](https://cyberoo.com/en/cybersecurity-company/)
          - [Certifications](https://cyberoo.com/en/certifications/)
          - [People](https://cyberoo.com/en/people-in-cybersecurity/)
          - [Above The Rest](https://cyberoo.com/en/above-the-rest/)
          - [Jobs](https://cyberoo.com/en/jobs/)
    - Investors 
          - [Investors relations](https://cyberoo.com/en/investors-relations/)
          - [Sustainability](https://cyberoo.com/en/sustainability/)
- Resources 
    - [Cyber Blog](https://blog.cyberoo.com/en)
    - [Tech Blog](https://cert.cyberoo.com/en/)
    - [Press News](https://cyberoo.com/en/news-press/)
    - [Media Kit](https://cyberoo.com/en/media-kit/)
- [Contacts](https://cyberoo.com/contacts/)
- [English](https://blog.cyberoo.com/en) 
    - [Italiano](https://blog.cyberoo.com/)
    - [Français](https://cyberoo.com/fr/)
    - [Deutsch](https://cyberoo.com/de/)
    - [Polski](https://blog.cyberoo.com/pl)
    - [Español](https://cyberoo.com/es/)

- <https://twitter.com/CYBEROO_ITALIA>
- <https://www.linkedin.com/company/cyberoo/>
- <https://www.youtube.com/channel/UC7AwVDG9Ngdwohk_zPd25xQ>
- <https://www.instagram.com/cyberoo_official/>
- <https://t.me/cyberoo_tech_blog>

![](https://blog.cyberoo.com/hubfs/Cyberoo%20Blog%20-%20Grafiche%20di%20copertina%20(4)-Nov-05-2026-08-54-55-7241-AM.gif)

# 10 technical errors that leave the door open to cybercriminals (and how to avoid them)

 Published by [Andrea Lusetti](https://blog.cyberoo.com/en/author/andrea-lusetti) on  5 November 2026

#### Listen the article

«

»

0:00

0:00 

1x 1.5x 2x 

 Il tuo browser non supporta l'audio.

 

Imagine servers that were set up for a project and have remained switched on even after the project has ended. The person who managed them has moved on to a different role, the software is still running an old version, and one service is still accessible from the internet. Communications with other company resources and certain permissions have remained active. An exploitable vulnerability or compromised credentials could allow a cybercriminal to gain **initial access**. From there, the ability to reach other systems would depend on network controls, available privileges and any further weaknesses present.

Inventory, updates and access can be managed by different people. In the servers we have considered, however, the consequences of their decisions are intertwined. Cyberoo’s approach to **systemic cybersecurity** starts with these connections: analysing technical weaknesses, responsibilities and the **consequences for business operations** as a whole. Vulnerabilities also warrant attention for what they enable an attacker to achieve.

The ten errors listed below relate to different stages: some may facilitate entry, others the propagation of the attack or the prolongation of downtime. For each one, the technical fix must be accompanied by a review: who is responsible for it, how do we detect misuse, and what measures can we put in place? Priorities depend on the likelihood of compromise and the consequences for the services involved.

 

## **Mistake #1: leaving assets off the inventory**

An **incomplete inventory** makes it difficult to understand which systems to update, monitor or decommission. The problem also affects virtual machines, cloud applications and connected devices: a service may continue to exist long after someone has stopped managing it.

An asset’s profile should help inform decision-making. It should specify a responsible person, the function performed, the data processed, dependencies and the software’s support status. Identifiers must allow the resource to be recognised even when network addresses or configurations change. The inventory must cover devices, software, virtual environments and cloud services, including those set up outside the standard IT processes.

To rectify this error, it is advisable to **update the inventory whenever changes occur and reconcile it with the resources actually identified**. The information can be sourced from management tools, cloud platforms and network scans. In industrial environments, discovery activities must be agreed with plant managers and compatible with process safety. Any unknown item must be verified before deciding how to manage it, restrict access to it or decommission it.

The inventory must then be usable by those monitoring security: knowing which service a machine belongs to helps to interpret an anomaly and assess its consequences. Decommissioning also requires a procedure, involving the revocation of access rights and the management of any remaining data.

 

## **Mistake #2: updating according to a schedule rather than risk**

Two vulnerabilities with the same severity score may require different responses. One affects an isolated application; the other, a service accessible via the internet that grants access to confidential information. **Exposure and consequences determine the priority.**

Patch management must take into account **technical severity, evidence of exploitation, exposure and business impact**. Even internal vulnerabilities can be urgent if they allow privileges to be escalated or critical services to be accessed. Scheduled patch windows remain useful, alongside an accelerated procedure for high-priority cases. Compatibility must be checked, a rollback to the previous configuration prepared if necessary, and the effective application of the fix verified.

Where installation takes time, temporary measures such as restricting access, disabling the vulnerable function or isolating the services may be considered. These exceptions require **a designated person and a deadline**.

Those responsible for monitoring must be aware of which systems remain exposed, so as to focus checks on possible signs of exploitation. Temporary mitigations must be verified and the residual risk documented. For end-of-support products, a replacement or decommissioning plan is required. If there are indications of a compromise, **the update must be accompanied by an incident analysis**: the patch fixes the vulnerabilities, whilst any persistent access requires further action.

 

## **Mistake #3: too many privileges and insufficient protection of credentials**

A compromised account allows the attacker to act with the account holder’s permissions. If those permissions are excessive, the potential impact also increases. Shared accounts, forgotten user accounts and administrative credentials used for day-to-day work also make it more difficult to trace accountability for access.

The solution starts with individual identities, **privileges limited to necessary tasks** and the prompt revocation of access when roles or employment relationships change. Administrative accounts must be separated from those used for routine tasks. For human access, particularly privileged and remote access, **phishing-resistant MFA** should be prioritised, for example using correctly configured FIDO2/WebAuthn. One-time codes add protection compared to passwords alone, but they can be captured and relayed via phishing sites. Authenticator registration, account recovery and sessions also require controls: strong authentication still leaves devices and already open sessions vulnerable.

Software identities require parallel efforts. **Service accounts, API keys and other application secrets** must be inventoried, assigned to a responsible person and granted only the necessary permissions. Where possible, it is advisable to use short-lived credentials and dedicated secret management systems, avoiding embedding them in code or shared files. Rotation and revocation must be managed without disrupting applications; in the event of a breach, credentials must be replaced and access attempts verified.

External information also plays a role: CSI, Cyberoo’s Cyber Threat Intelligence service, monitors, amongst other threats, **compromised credentials and exposed data**. A match requires verification of its relevance and timeliness, followed by action on the affected accounts. However, the failure to detect exposed credentials still makes it necessary to perform monitoring of internal access.

 

## **Mistake #4: exposing administrative services without a verified need**

An administration panel accessible via the Internet expands the company’s **attack surface**. Exposure, in itself, is not the same as a compromise; however, it increases the opportunities for the service to be scrutinised and attacked. A password protects the intended access to the application, whilst any vulnerabilities in the service may require further checks.

An external audit helps to **compare actual exposure with expected exposure**, including cloud configurations and access rules. For each service, it is advisable to clarify who should use it, from where and for what purpose. Administrative interfaces without an operational necessity should be removed from public exposure. Essential access points require controlled channels, strong authentication, updates and monitoring. Systems that facilitate remote access must also be protected: a VPN is itself a service that requires management.

The configuration must be rechecked following migrations, maintenance and vendor interventions. A temporary rule may outlive the task for which it was created. Documenting its **owner and duration** helps prevent an exception from becoming a permanent part of the infrastructure.

 

## **Mistake #5: confusing a successful backup with the ability to restart**

The message ‘backup completed’ confirms that a copy operation has taken place. Restarting requires a different verification process: **recovering intact data**, rebuilding dependencies and bringing usable applications back online. An available archive may prove insufficient if configurations, credentials or components necessary for recovery are missing.

Recovery must restore systems to **a reliable state**. During an incident, an attacker may have modified configurations, accounts and software prior to the most recent backup. It is therefore necessary to select a verified recovery point, contain the compromise and remove its causes, rebuilding the systems if necessary. Data recovery helps to resume operations, but leaves the consequences of any information theft to be managed.

**Isolated or offline copies, and where appropriate, immutable ones** are required, with separate administrative access and protections against deletion. Isolation and immutability offer different properties and must be verified in the actual configuration. Tests must restore usable services in a controlled environment, involving the end-users. Recovery times and recovery points must be compared against two agreed objectives: **RTO**, the time within which the service must be restored, and **RPO**, the point in time to which data must be restored, which expresses the tolerable data loss in terms of time.

 

## **Mistake #6: collecting logs that nobody can correlate**

An unexpected access event, a change in privileges and an unusual data transfer may appear in different monitoring systems. **Correlating events with their context** helps to identify a possible attack sequence. An anomaly may also have a legitimate explanation: the investigation must consider the identity, the resource involved, authorised activities and other available evidence.

Log management requires precise decisions: which sources to include, relevant events, retention periods and authorised access. **Centralised collection or coordinated access, synchronised timestamps and protection against tampering** are essential. Delays and interruptions in collection must also be monitored. The information must be sufficient for analysis, whilst limiting the inclusion of superfluous personal data and confidential information in the logs.

It is advisable to start with concrete use cases, such as unexpected administrative access or a change in permissions for confidential data. For each case, the necessary sources, analysis criteria and a verification procedure are required. Detection rules must be tested and updated: logging alone leaves the work of interpretation and response unresolved.

This is the work to which a **Managed Detection and Response** service contributes: analysing indicators and linking them to threat management. With Cypeer, Cyberoo integrates technologies and specialist expertise for **24/7 active detection, analysis and response** activities. Actual coverage depends on the available sources and integrations: scope, responsibilities, authorisations and response procedures must be agreed with the company’s team.

 

## **Mistake #7: leaving incident response to improvisation**

During an incident, it may be necessary to isolate a system that supports a critical business function. This decision involves security, operational continuity and corporate accountability. Reaching that point without having clarified **who can authorise the intervention** adds uncertainty to an already difficult situation.

A workable plan must specify **point persons, deputies, escalations and decision-making authorities**. Procedures must coordinate analysis, containment, evidence preservation, threat removal and recovery, with priorities commensurate with the incident. Urgent interventions and those involving industrial systems require preventive criteria that also take into account the safety of people and processes. Alternative contacts and channels must be available if email and internal systems are inaccessible; communications and the assessment of notification obligations must be entrusted to the relevant points of contact.

**Drills** help to validate these choices. Table-top simulations test roles and decision-making; technical tests in controlled environments verify procedures and tools. Both must result in concrete corrective actions, to be assigned and verified, alongside the lessons learnt from real incidents.

If monitoring is entrusted to an external partner, the test must also involve the points of contact and the **agreed authorisations**: who receives the alert, who assesses the impact, and who can order the system to be isolated? Upon completion, every issue that has emerged should result in a corrective action assigned to someone and subsequently verified.

 

## **Mistake #8: allowing a single point of access to reach too many systems**

In a poorly segmented network, a compromised device may have communication paths to systems performing very different functions. Extensive permissions and reused administrative credentials can further expand the attacker’s scope of movement.

Segmentation serves to **limit communications and contain the spread of threats**. To design it, one must understand the necessary traffic flows: sources, destinations, protocols and functions performed. From this, rules are defined to allow only justified communications, specifically separating administrative domains and assessing the interconnections between IT and industrial systems. Changes must be tested with operational managers.

VLANs separate network domains, but restricting traffic between them requires **rules to be applied and verified on firewalls or other control points**. Alternative routes and remote connections must also be taken into account. In terms of identities, separate administrative credentials and restricted privileges further limit the attacker’s movement. Segmentation helps to contain the attack, whilst detection and response remain necessary even within individual areas.

 

## **Mistake #9: connecting AI tools to business data without restricting access**

An AI assistant that reads confidential documents can expose information even when it only has read-only access. If it can also modify data or activate tools, the potential consequences increase. The assessment must cover **accessible data, permissions, permitted operations and the destinations of the information**, including tools used outside of established business processes.

**Prompt injection** is an attempt to make the model treat content controlled by an attacker as instructions, thereby diverting its behaviour. It can originate directly from an interaction or from documents, web pages and other materials that the assistant consults. Separating instructions from data, verifying outputs and testing for these attacks helps to reduce the risk; however, access restrictions must also be applied outside the model.

The starting point is to take stock of tools and integrations, authorising only the necessary data and functions. Sensitive operations require **controls within the component that executes them** and, where applicable, approvals linked to the exact action, resource and parameters. Human approval must be complemented by technical checks, traceability and operational limits. Even read-only access requires safeguards against disclosure: a security prompt, on its own, offers different guarantees to a system-enforced authorisation.

 

## **Mistake #10: neglecting access and dependencies on suppliers**

A supplier may access the network for maintenance, to manage an application or to store data necessary for their work. The risk also extends to software and components embedded in purchased products. Compromised access, tampered updates or vulnerabilities in dependencies can affect the client organisation. Service unavailability also introduces a business continuity risk, even in the absence of an intrusion into the internal network.

The audit must clarify the services provided, the data processed, **access rights and critical dependencies**. The assessment must be proportionate to the potential impact and kept up to date. Certifications, audit reports and contractual clauses provide evidence to be examined within their respective scope, alongside the technical conditions of the service. For critical software, knowing the components and versions helps to identify vulnerable dependencies, provided the information is up to date and used to take action.

With regard to access, there must be user accounts attributable to identified individuals or services, appropriate authentication, restricted privileges and **access limited to what is strictly necessary**. Administrative sessions must be logged according to risk, and access rights revoked when the conditions justifying them cease to exist. Contracts and procedures must clarify incident reporting, collaboration in the response and the management of service termination, including data and credentials.

Information on suppliers must also reach those responsible for security: a maintenance connection or an administrative task can be better understood when **authorisations and planned interventions** are known. A periodic joint review helps to ensure consistency between access rights, the people involved and the activities actually carried out.

## **From technical rectification to risk management**

The ten errors described require precise technical interventions. However, managing them also involves those who set priorities, authorise changes and are accountable for the consequences for the organisation. When these activities remain separate, a weakness may be identified without it being clear who should rectify it or how urgently. Bringing **expertise, technologies and processes** together means linking every piece of evidence to a decision and assessing its impact on risk.

This marks the transition from protecting individual systems to **managing cyber risk as a business risk**. Vulnerabilities must also be assessed in terms of the operations they could disrupt, whilst compromised access must be evaluated in terms of the data and processes it enables access to. Technical decisions must therefore be shared with those who understand the operational interdependencies and can establish responsibilities, timelines and priorities. The guiding principle becomes the risk to be mitigated, from which the necessary actions and capabilities are derived.

Cyberoo translates this vision into **ORBIS, the strategic and operational model for integrated cyber risk management**. Threat Management, Processes and Governance, Regulatory and Compliance, and People Security are integrated within a common framework. The aim is to clarify priorities and responsibilities, coordinating the ability to detect, decide and intervene with the requirements of operational continuity, compliance and human factor management.

The collaboration with Cyberoo therefore begins with **the organisation’s risks and the relationships that may amplify them**: between systems and identities, people and procedures, suppliers and operational activities. Based on this analysis, we determine how to integrate existing capabilities and where to intervene to address any gaps. Correcting technical errors thus becomes part of a continuous process, in which evidence, decisions and actions remain interconnected.

![Andrea Lusetti](https://blog.cyberoo.com/hs-fs/hubfs/Speaker%20webinar%20(12).jpg?width=96&height=96&name=Speaker%20webinar%20(12).jpg)

[**Andrea Lusetti**](https://blog.cyberoo.com/en/author/andrea-lusetti) Andrea Lusetti

 Cybersecurity Analyst - CYBEROO

[LinkedIn](https://www.linkedin.com/in/andrea-lusetti-a41a063/)

 

Tags: [Governance & Processes](https://blog.cyberoo.com/en/tag/governance-processes)

[Back to Blog](https://blog.cyberoo.com/en)

- [Tweet](https://twitter.com/share)

[![Cyberoo](https://blog.cyberoo.com/hubfs/raw_assets/public/Cyberoo_May2023/images/CYBEROO-logo.svg "Cyberoo")](https://blog.cyberoo.com/)

**TRUSTED BY USERS**

[![Capterra](https://blog.cyberoo.com/hubfs/raw_assets/public/Cyberoo_May2023/images/a0e3aa33abf348490d739e99e692012d.svg "Capterra")](https://www.capterra.com/reviews/206253/Cyber-Security-Suite?utm_source=vendor&utm_medium=badge&utm_campaign=capterra_reviews_badge)

![Gartner Peer](https://blog.cyberoo.com/hubfs/raw_assets/public/Cyberoo_May2023/images/GartnerPeerInsightsLogo-white.svg "Gartner Peer")

- SERVICES 
    - [CYPEER](https://cyberoo.com/en/managed-detection-and-response/)
    - [CSI](https://cyberoo.com/en/threat-intelligence/)
    - [INCIDENT RESPONSE](https://cyberoo.com/en/incident-response/)
    - [TITAAN NEEMESI](https://cyberoo.com/en/titaan-neemesi/)
    - [KEATRIX](https://cyberoo.com/en/keatrix-security-awareness-training/)

- USEFUL LINKS 
    - [WE ARE CYBEROO](https://cyberoo.com/en/company/)
    - [BLOG](https://blog.cyberoo.com/en)
    - [CONTACTS](https://cyberoo.com/en/contacts/)

© 2026 Cyberoo.  
Registered Office: Via Brigata Reggio, 37 - 42124 Reggio Emilia (RE) - PEC amministrazione@pec.cyberoo.com  
Fully paid-up share capital € 1.035.432,35 Tax Code and VAT No. 04318950286 - R.E.A. RE 288453  
[Privacy Policy](https://cyberoo.com/privacy-policy/) - [Privacy Policy - National Register of State Aids](https://www.rna.gov.it/RegistroNazionaleTrasparenza/faces/pages/TrasparenzaAiuto.jspx)- ISO27001

- <https://twitter.com/CYBEROO_ITALIA>
- <https://www.linkedin.com/company/cyberoo/>
- <https://www.youtube.com/channel/UC7AwVDG9Ngdwohk_zPd25xQ>

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Andrea Lusetti",
    "url" : "https://blog.cyberoo.com/en/author/andrea-lusetti"
  },
  "dateModified" : "2026-11-05T09:00:06.266Z",
  "datePublished" : "2026-11-05T09:00:06.000Z",
  "headline" : "10 technical errors that leave the door open to cybercriminals (and how to avoid them)",
  "image" : [ "https://blog.cyberoo.com/hubfs/Cyberoo%20Blog%20-%20Grafiche%20di%20copertina%20(4)-Nov-05-2026-08-54-55-7241-AM.gif" ],
  "mainEntityOfPage" : {
    "@id" : "https://blog.cyberoo.com/en/10-errori-tecnici-che-aprono-la-porta-ai-cybercriminali-e-come-evitarli",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/vast.png"
    },
    "name" : "Cyberoo"
  }
}
```

```json
{
  "@context" : "https://schema.org",
  "@type" : "Article",
  "about" : {
    "@type" : "Thing",
    "name" : "Governance & Processes"
  },
  "articleBody" : "Listen the article « » 0:00 0:00 1x 1.5x 2x Il tuo browser non supporta l'audio. Imagine servers that were set up for a project and have remained switched on even after the project has ended. The person who managed them has moved on to a different role, the software is still running an old version, and one service is still accessible from the internet. Communications with other company resources and certain permissions have remained active. An exploitable vulnerability or compromised credentials could allow a cybercriminal to gain initial access. From there, the ability to reach other systems would depend on network controls, available privileges and any further weaknesses present. Inventory, updates and access can be managed by different people. In the servers we have considered, however, the consequences of their decisions are intertwined. Cyberoo’s approach to systemic cybersecurity starts with these connections: analysing technical weaknesses, responsibilities and the consequences for business operations as a whole. Vulnerabilities also warrant attention for what they enable an attacker to achieve. The ten errors listed below relate to different stages: some may facilitate entry, others the propagation of the attack or the prolongation of downtime. For each one, the technical fix must be accompanied by a review: who is responsible for it, how do we detect misuse, and what measures can we put in place? Priorities depend on the likelihood of compromise and the consequences for the services involved. Mistake #1: leaving assets off the inventory An incomplete inventory makes it difficult to understand which systems to update, monitor or decommission. The problem also affects virtual machines, cloud applications and connected devices: a service may continue to exist long after someone has stopped managing it. An asset’s profile should help inform decision-making. It should specify a responsible person, the function performed, the data processed, dependencies and the software’s support status. Identifiers must allow the resource to be recognised even when network addresses or configurations change. The inventory must cover devices, software, virtual environments and cloud services, including those set up outside the standard IT processes. To rectify this error, it is advisable to update the inventory whenever changes occur and reconcile it with the resources actually identified. The information can be sourced from management tools, cloud platforms and network scans. In industrial environments, discovery activities must be agreed with plant managers and compatible with process safety. Any unknown item must be verified before deciding how to manage it, restrict access to it or decommission it. The inventory must then be usable by those monitoring security: knowing which service a machine belongs to helps to interpret an anomaly and assess its consequences. Decommissioning also requires a procedure, involving the revocation of access rights and the management of any remaining data. Mistake #2: updating according to a schedule rather than risk Two vulnerabilities with the same severity score may require different responses. One affects an isolated application; the other, a service accessible via the internet that grants access to confidential information. Exposure and consequences determine the priority. Patch management must take into account technical severity, evidence of exploitation, exposure and business impact. Even internal vulnerabilities can be urgent if they allow privileges to be escalated or critical services to be accessed. Scheduled patch windows remain useful, alongside an accelerated procedure for high-priority cases. Compatibility must be checked, a rollback to the previous configuration prepared if necessary, and the effective application of the fix verified. Where installation takes time, temporary measures such as restricting access, disabling the vulnerable function or isolating the services may be considered. These exceptions require a designated person and a deadline. Those responsible for monitoring must be aware of which systems remain exposed, so as to focus checks on possible signs of exploitation. Temporary mitigations must be verified and the residual risk documented. For end-of-support products, a replacement or decommissioning plan is required. If there are indications of a compromise, the update must be accompanied by an incident analysis: the patch fixes the vulnerabilities, whilst any persistent access requires further action. Mistake #3: too many privileges and insufficient protection of credentials A compromised account allows the attacker to act with the account holder’s permissions. If those permissions are excessive, the potential impact also increases. Shared accounts, forgotten user accounts and administrative credentials used for day-to-day work also make it more difficult to trace accountability for access. The solution starts with individual identities, privileges limited to necessary tasks and the prompt revocation of access when roles or employment relationships change. Administrative accounts must be separated from those used for routine tasks. For human access, particularly privileged and remote access, phishing-resistant MFA should be prioritised, for example using correctly configured FIDO2/WebAuthn. One-time codes add protection compared to passwords alone, but they can be captured and relayed via phishing sites. Authenticator registration, account recovery and sessions also require controls: strong authentication still leaves devices and already open sessions vulnerable. Software identities require parallel efforts. Service accounts, API keys and other application secrets must be inventoried, assigned to a responsible person and granted only the necessary permissions. Where possible, it is advisable to use short-lived credentials and dedicated secret management systems, avoiding embedding them in code or shared files. Rotation and revocation must be managed without disrupting applications; in the event of a breach, credentials must be replaced and access attempts verified. External information also plays a role: CSI, Cyberoo’s Cyber Threat Intelligence service, monitors, amongst other threats, compromised credentials and exposed data. A match requires verification of its relevance and timeliness, followed by action on the affected accounts. However, the failure to detect exposed credentials still makes it necessary to perform monitoring of internal access. Mistake #4: exposing administrative services without a verified need An administration panel accessible via the Internet expands the company’s attack surface. Exposure, in itself, is not the same as a compromise; however, it increases the opportunities for the service to be scrutinised and attacked. A password protects the intended access to the application, whilst any vulnerabilities in the service may require further checks. An external audit helps to compare actual exposure with expected exposure, including cloud configurations and access rules. For each service, it is advisable to clarify who should use it, from where and for what purpose. Administrative interfaces without an operational necessity should be removed from public exposure. Essential access points require controlled channels, strong authentication, updates and monitoring. Systems that facilitate remote access must also be protected: a VPN is itself a service that requires management. The configuration must be rechecked following migrations, maintenance and vendor interventions. A temporary rule may outlive the task for which it was created. Documenting its owner and duration helps prevent an exception from becoming a permanent part of the infrastructure. Mistake #5: confusing a successful backup with the ability to restart The message ‘backup completed’ confirms that a copy operation has taken place. Restarting requires a different verification process: recovering intact data, rebuilding dependencies and bringing usable applications back online. An available archive may prove insufficient if configurations, credentials or components necessary for recovery are missing. Recovery must restore systems to a reliable state. During an incident, an attacker may have modified configurations, accounts and software prior to the most recent backup. It is therefore necessary to select a verified recovery point, contain the compromise and remove its causes, rebuilding the systems if necessary. Data recovery helps to resume operations, but leaves the consequences of any information theft to be managed. Isolated or offline copies, and where appropriate, immutable ones are required, with separate administrative access and protections against deletion. Isolation and immutability offer different properties and must be verified in the actual configuration. Tests must restore usable services in a controlled environment, involving the end-users. Recovery times and recovery points must be compared against two agreed objectives: RTO, the time within which the service must be restored, and RPO, the point in time to which data must be restored, which expresses the tolerable data loss in terms of time. Mistake #6: collecting logs that nobody can correlate An unexpected access event, a change in privileges and an unusual data transfer may appear in different monitoring systems. Correlating events with their context helps to identify a possible attack sequence. An anomaly may also have a legitimate explanation: the investigation must consider the identity, the resource involved, authorised activities and other available evidence. Log management requires precise decisions: which sources to include, relevant events, retention periods and authorised access. Centralised collection or coordinated access, synchronised timestamps and protection against tampering are essential. Delays and interruptions in collection must also be monitored. The information must be sufficient for analysis, whilst limiting the inclusion of superfluous personal data and confidential information in the logs. It is advisable to start with concrete use cases, such as unexpected administrative access or a change in permissions for confidential data. For each case, the necessary sources, analysis criteria and a verification procedure are required. Detection rules must be tested and updated: logging alone leaves the work of interpretation and response unresolved. This is the work to which a Managed Detection and Response service contributes: analysing indicators and linking them to threat management. With Cypeer, Cyberoo integrates technologies and specialist expertise for 24/7 active detection, analysis and response activities. Actual coverage depends on the available sources and integrations: scope, responsibilities, authorisations and response procedures must be agreed with the company’s team. Mistake #7: leaving incident response to improvisation During an incident, it may be necessary to isolate a system that supports a critical business function. This decision involves security, operational continuity and corporate accountability. Reaching that point without having clarified who can authorise the intervention adds uncertainty to an already difficult situation. A workable plan must specify point persons, deputies, escalations and decision-making authorities. Procedures must coordinate analysis, containment, evidence preservation, threat removal and recovery, with priorities commensurate with the incident. Urgent interventions and those involving industrial systems require preventive criteria that also take into account the safety of people and processes. Alternative contacts and channels must be available if email and internal systems are inaccessible; communications and the assessment of notification obligations must be entrusted to the relevant points of contact. Drills help to validate these choices. Table-top simulations test roles and decision-making; technical tests in controlled environments verify procedures and tools. Both must result in concrete corrective actions, to be assigned and verified, alongside the lessons learnt from real incidents. If monitoring is entrusted to an external partner, the test must also involve the points of contact and the agreed authorisations: who receives the alert, who assesses the impact, and who can order the system to be isolated? Upon completion, every issue that has emerged should result in a corrective action assigned to someone and subsequently verified. Mistake #8: allowing a single point of access to reach too many systems In a poorly segmented network, a compromised device may have communication paths to systems performing very different functions. Extensive permissions and reused administrative credentials can further expand the attacker’s scope of movement. Segmentation serves to limit communications and contain the spread of threats. To design it, one must understand the necessary traffic flows: sources, destinations, protocols and functions performed. From this, rules are defined to allow only justified communications, specifically separating administrative domains and assessing the interconnections between IT and industrial systems. Changes must be tested with operational managers. VLANs separate network domains, but restricting traffic between them requires rules to be applied and verified on firewalls or other control points. Alternative routes and remote connections must also be taken into account. In terms of identities, separate administrative credentials and restricted privileges further limit the attacker’s movement. Segmentation helps to contain the attack, whilst detection and response remain necessary even within individual areas. Mistake #9: connecting AI tools to business data without restricting access An AI assistant that reads confidential documents can expose information even when it only has read-only access. If it can also modify data or activate tools, the potential consequences increase. The assessment must cover accessible data, permissions, permitted operations and the destinations of the information, including tools used outside of established business processes. Prompt injection is an attempt to make the model treat content controlled by an attacker as instructions, thereby diverting its behaviour. It can originate directly from an interaction or from documents, web pages and other materials that the assistant consults. Separating instructions from data, verifying outputs and testing for these attacks helps to reduce the risk; however, access restrictions must also be applied outside the model. The starting point is to take stock of tools and integrations, authorising only the necessary data and functions. Sensitive operations require controls within the component that executes them and, where applicable, approvals linked to the exact action, resource and parameters. Human approval must be complemented by technical checks, traceability and operational limits. Even read-only access requires safeguards against disclosure: a security prompt, on its own, offers different guarantees to a system-enforced authorisation. Mistake #10: neglecting access and dependencies on suppliers A supplier may access the network for maintenance, to manage an application or to store data necessary for their work. The risk also extends to software and components embedded in purchased products. Compromised access, tampered updates or vulnerabilities in dependencies can affect the client organisation. Service unavailability also introduces a business continuity risk, even in the absence of an intrusion into the internal network. The audit must clarify the services provided, the data processed, access rights and critical dependencies. The assessment must be proportionate to the potential impact and kept up to date. Certifications, audit reports and contractual clauses provide evidence to be examined within their respective scope, alongside the technical conditions of the service. For critical software, knowing the components and versions helps to identify vulnerable dependencies, provided the information is up to date and used to take action. With regard to access, there must be user accounts attributable to identified individuals or services, appropriate authentication, restricted privileges and access limited to what is strictly necessary. Administrative sessions must be logged according to risk, and access rights revoked when the conditions justifying them cease to exist. Contracts and procedures must clarify incident reporting, collaboration in the response and the management of service termination, including data and credentials. Information on suppliers must also reach those responsible for security: a maintenance connection or an administrative task can be better understood when authorisations and planned interventions are known. A periodic joint review helps to ensure consistency between access rights, the people involved and the activities actually carried out. From technical rectification to risk management The ten errors described require precise technical interventions. However, managing them also involves those who set priorities, authorise changes and are accountable for the consequences for the organisation. When these activities remain separate, a weakness may be identified without it being clear who should rectify it or how urgently. Bringing expertise, technologies and processes together means linking every piece of evidence to a decision and assessing its impact on risk. This marks the transition from protecting individual systems to managing cyber risk as a business risk. Vulnerabilities must also be assessed in terms of the operations they could disrupt, whilst compromised access must be evaluated in terms of the data and processes it enables access to. Technical decisions must therefore be shared with those who understand the operational interdependencies and can establish responsibilities, timelines and priorities. The guiding principle becomes the risk to be mitigated, from which the necessary actions and capabilities are derived. Cyberoo translates this vision into ORBIS, the strategic and operational model for integrated cyber risk management. Threat Management, Processes and Governance, Regulatory and Compliance, and People Security are integrated within a common framework. The aim is to clarify priorities and responsibilities, coordinating the ability to detect, decide and intervene with the requirements of operational continuity, compliance and human factor management. The collaboration with Cyberoo therefore begins with the organisation’s risks and the relationships that may amplify them: between systems and identities, people and procedures, suppliers and operational activities. Based on this analysis, we determine how to integrate existing capabilities and where to intervene to address any gaps. Correcting technical errors thus becomes part of a continuous process, in which evidence, decisions and actions remain interconnected. Andrea Lusetti Andrea Lusetti Cybersecurity Analyst - CYBEROO LinkedIn",
  "author" : {
    "@type" : "Person",
    "name" : "Andrea Lusetti",
    "sameAs" : [ "https://www.linkedin.com/in/andrea-lusetti-a41a063/" ],
    "url" : "https://blog.cyberoo.com/en/author/andrea-lusetti"
  },
  "dateModified" : "1793869206274",
  "datePublished" : "2026-11-05 09:00:06",
  "description" : "Discover 10 technical errors that can expose your organization to cybercriminals and learn how to mitigate them effectively. Secure your systems today.",
  "editor" : {
    "@type" : "Person",
    "name" : "Andrea Lusetti"
  },
  "headline" : "10 technical errors that leave the door open to cybercriminals (and how to avoid them)",
  "image" : {
    "@type" : "ImageObject",
    "height" : 675,
    "url" : "https://content.cyberoo.com/hubfs/Cyberoo%20Blog%20-%20Grafiche%20di%20copertina%20%284%29-Nov-05-2026-08-54-55-7241-AM.gif",
    "width" : 1200
  },
  "inLanguage" : "it-IT",
  "isAccessibleForFree" : true,
  "mainEntityOfPage" : {
    "@id" : "https://blog.cyberoo.com/en/10-errori-tecnici-che-aprono-la-porta-ai-cybercriminali-e-come-evitarli",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : ""
    },
    "name" : "Blog",
    "sameAs" : [ "https://www.linkedin.com/company/cyberoo-italia" ]
  },
  "url" : "https://blog.cyberoo.com/en/10-errori-tecnici-che-aprono-la-porta-ai-cybercriminali-e-come-evitarli",
  "wordCount" : 2745
}
```