The Universal Starting Point: Default Configurations Are Not Secure
Every system — regardless of type — ships with a default configuration. That default exists to ensure the system works out of the box, that it can communicate, and that it can be set up by someone without deep security knowledge. Default configurations optimize for usability and compatibility, not for security. Open ports, weak default credentials, unnecessary services running, verbose logging disabled, authentication turned off to ease initial setup — these are the norms. Without deliberate hardening, every deployed system starts its operational life with attack surface that should not exist.
The starting point for hardening any system is a hardening guide specific to that platform. Manufacturers — the people who built the software or hardware — are the best source for platform-specific hardening recommendations. They understand their own product's attack surface, default behaviors, and security-relevant configuration options better than anyone. If no manufacturer guide exists, third-party security organizations (CIS, NIST, DISA STIGs) publish platform-specific benchmarks covering many common operating systems, applications, and appliances. The right guide depends on the platform being hardened; a Windows Server guide is not a substitute for an iOS MDM hardening checklist.
Mobile Devices — Always Connected, Always a Target
Smartphones and tablets are permanently connected to networks — cellular, Wi-Fi, Bluetooth, and cloud synchronization running simultaneously. This constant connectivity is valuable for productivity and equally valuable for attackers. Mobile devices access corporate email, VPNs, cloud applications, and sensitive data from locations and networks that IT has no control over. Every unpatched vulnerability is a potential entry point.
Updates are the first line of defense. Mobile operating system updates contain security patches that close known vulnerabilities. Delaying updates leaves devices exposed to attacks that the manufacturer has already fixed. This is especially consequential because mobile exploits are often public knowledge — the same advisory that tells defenders a vulnerability exists tells attackers exactly what to target on unpatched devices.
Data segmentation separates corporate from personal. When an employee uses a company-managed mobile device, there are typically two categories of data: corporate data (email, applications, files belonging to the organization) and personal data (the employee's own photos, messages, apps). Segmenting these into separate logical containers — often called a work profile or managed container — means that a security incident in one segment does not expose the other. If corporate data is compromised, the employee's personal data is not affected; if personal apps introduce malware, corporate resources are protected from lateral access.
MDM is the operational control layer. Managing security policies on dozens or hundreds of mobile devices manually is impractical. A Mobile Device Management (MDM) platform provides centralized administrative control: pushing configuration policies to enrolled devices, enforcing screen lock requirements, ensuring encryption is enabled, controlling which applications can be installed, and performing remote wipe when a device is lost or stolen. MDM makes mobile hardening scalable — define the policy once and push it to every device in the fleet.
Workstations — The Most Targeted Endpoint
Workstations — desktops and laptops running Windows, macOS, or Linux — are the most common attack target in enterprise environments. They are where users receive phishing emails, browse the web, open attachments, and run applications. Compromising a workstation is often the first step of a larger intrusion. Hardening workstations reduces the success rate of initial access attempts and limits what an attacker can do with a compromised endpoint.
Comprehensive, timely updates cover three layers. The operating system itself receives security patches — Windows Update, macOS Software Update, Linux package managers. Applications running on the OS also have their own update cycles — browsers, productivity suites, plugins. The firmware of the device (BIOS/UEFI, drivers) also requires updates. Each layer can contain exploitable vulnerabilities, and patches for all three must be managed, not just OS patches. Many organizations automate patch deployment on a monthly cycle aligned to patch Tuesday (Microsoft's monthly patch release), testing patches in a pilot group before broad deployment to catch compatibility issues before they affect the whole fleet.
Policy management enforces settings consistently. Workstations connected to Active Directory receive configuration through Group Policy — centrally defined security settings that are pushed automatically and reapplied regularly, overriding local changes. This handles password complexity requirements, firewall settings, application restrictions, and dozens of other hardening settings without requiring manual configuration on each machine.
Remove unnecessary software. Every installed application is a potential attack vector. An application with a known vulnerability is exploitable regardless of how well the OS is hardened. Removing software that is no longer needed, uninstalling browser plugins that are not actively used, and limiting the installed software inventory to only what is required for business function reduces the attack surface proportionally. Less software means fewer vulnerabilities to patch, fewer services running, and fewer entry points for an attacker.
Network Infrastructure — Invisible But Critical
Switches, routers, firewalls, and other network infrastructure devices form the backbone of enterprise communications. Users rarely interact with them directly, but their compromise is catastrophic — an attacker with control of a core switch can intercept, redirect, or drop traffic for the entire network. These devices are often overlooked in hardening programs because they are "invisible" in day-to-day operations, but they require the same systematic security attention as any other system.
Embedded operating systems create limited management surfaces. Unlike workstations and servers that run general-purpose operating systems, network infrastructure devices run purpose-built embedded operating systems — Cisco IOS, Juniper Junos, HPE Comware, and their equivalents. These are not Windows or Linux; they are minimal operating environments designed to do one job. The limited OS access means fewer configuration options are exposed, but it also means hardening must be done through the vendor-specific management interface, not through generic OS hardening tools.
Change default credentials immediately. Network infrastructure devices are among the most commonly exploited via default credentials. Many devices ship with well-known defaults (admin/admin, admin/password, or documented in public product manuals). Attackers know these defaults and actively scan for devices that have never had them changed. The first step in hardening any network device is changing every default credential. Where possible, configure authentication against a central authentication server (RADIUS, TACACS+) rather than local accounts — this provides centralized credential management and auditing.
Apply manufacturer patches, even though they are rare. Unlike workstations that receive patches monthly, network infrastructure firmware updates are infrequent. But when a manufacturer releases a security patch for a switch or router, it typically addresses a significant vulnerability. The rarity makes the importance of any single patch higher — if the manufacturer took the time to release an update, it addresses something worth fixing. Organizations should monitor manufacturer security advisories and apply firmware updates when they address relevant vulnerabilities.
Cloud Infrastructure — The Management Workstation Is the Crown Jewel
Cloud environments present a hardening challenge that differs fundamentally from on-premises infrastructure. In a traditional data center, an attacker who compromises a server has access to that server. In a cloud environment, an attacker who compromises the cloud management console or a highly privileged administrative account may have access to every virtual machine, every storage bucket, every network configuration, and every service the organization runs in that cloud. The blast radius of a single credential compromise can be the entire cloud infrastructure.
The cloud management workstation — the computer used to administer cloud resources — is therefore one of the most critical assets in the organization. It often has the credentials and access tokens that control the cloud environment. This workstation must be treated as a high-value target: hardened with the same rigor applied to the most sensitive servers, EDR-protected, patched on the fastest cycle, with access strictly limited to those who legitimately need it.
Least privilege is the architectural principle for cloud. Cloud environments make it very easy to grant broad permissions — a service account with administrator rights to everything is simpler to set up than one with carefully scoped permissions. This convenience is a security trap. Every service, application, and user account in the cloud should have only the permissions required to perform its specific function. A Lambda function that reads from one S3 bucket should not have write access to any bucket. A backup service that needs to read VMs should not have the ability to delete them. Misconfigured cloud permissions are one of the most common causes of cloud security incidents, and least privilege is the systematic defense.
EDR on all cloud-connected endpoints. Every device that accesses the cloud management environment should have Endpoint Detection and Response (EDR) installed. EDR goes beyond traditional antivirus — it monitors for behavioral indicators of compromise, detects anomalous activity, and can respond to threats in real time. If a workstation that has cloud management access is compromised, EDR provides the visibility to detect the compromise before the attacker can pivot to the cloud environment.
Cloud-to-Cloud (C2C) backups. Cloud environments are not immune to data loss — accidental deletion, ransomware encryption, provider outages, and misconfiguration can all result in lost data. The backup strategy for cloud resources should not rely solely on the same cloud provider hosting the primary data. Backing up to a second cloud provider — or at minimum to a second region under different credentials — ensures that a compromise or outage affecting the primary environment does not also affect the backup.
Servers — The Core of Business Operations
Servers are the workhorses of enterprise IT: database servers, web servers, application servers, file servers, authentication servers, mail servers. They run continuously, hold business-critical data, and are frequently the ultimate target of an intrusion that begins elsewhere. Server hardening combines OS-level security, account management, network access control, and continuous monitoring.
Keep OS patches and service packs current. Server operating systems — Windows Server, Red Hat Enterprise Linux, Ubuntu Server, and their equivalents — receive security patches regularly. Windows organizes major collections of patches into service packs; Linux distributions push patches through package managers. Any delay in applying security patches leaves known, public vulnerabilities open on systems that hold the organization's most valuable data. Server patching requires more care than workstation patching (server reboots have operational impact, patch compatibility testing is critical) but must not be deferred indefinitely.
Enforce strong authentication and account controls. Every account on a server — service accounts, administrative accounts, user accounts — should be governed by minimum password length and complexity requirements. Accounts that are no longer needed should be disabled or deleted rather than left dormant. Dormant accounts are an attacker's preferred tool: credentials for an account that nobody is monitoring, attached to an identity that may still have significant permissions. Least privilege applies to every account — service accounts need the minimum permissions to run their service, not local administrator rights to the entire machine.
Limit network access. A server that only communicates with a defined set of systems — a database server accessed only by specific application servers, for example — should have firewall rules that enforce exactly that. Network access control policies at both the server level and the perimeter reduce the paths an attacker can use to reach the server and limit the paths a compromised server can use to reach other systems. Open network access between servers within a network is a common configuration that enables lateral movement after an initial compromise.
Deploy EDR, antivirus, and antimalware. Servers require client-based security technology just as workstations do. Modern EDR platforms provide behavioral monitoring that detects attacks in progress — malware execution, credential dumping, unusual process behavior — rather than relying solely on signature matching. Servers without endpoint security provide no early warning of an active intrusion and limit the organization's ability to detect and contain an attack.
SCADA and ICS — When a Cyberattack Has Physical Consequences
Supervisory Control and Data Acquisition (SCADA) systems and Industrial Control Systems (ICS) manage physical infrastructure: power generation plants, water treatment facilities, oil and gas pipelines, manufacturing equipment, and logistics systems. These are not IT systems in the traditional sense — they interface with physical processes and hardware. A compromised SCADA system does not just result in data theft; it can result in a turbine running at dangerous speeds, a water treatment chemical dosing incorrectly, a manufacturing line producing defective products, or a power grid segment failing.
This physical consequence is why SCADA and ICS security receives dedicated treatment. The stakes are fundamentally different from a compromised database server. An ICS attack can cause injury, death, environmental damage, and critical infrastructure failure affecting thousands or millions of people. The Stuxnet worm, the Ukrainian power grid attacks, and the Florida water treatment facility incident all demonstrated that ICS systems are actively targeted and that the consequences of compromise are not hypothetical.
Extensive segmentation and air-gapping is the primary defense. SCADA systems are typically placed on their own isolated network, completely separated from the corporate IT network and with no direct internet connectivity. The concept of an air-gap — a physical separation with no network connection between the ICS network and external networks — is the gold standard for the most critical systems. Where some connectivity is required for monitoring or remote management, it is implemented through carefully controlled, one-directional data diodes or highly restricted jump servers with no general network access. "No access from the outside" is not just a best practice for ICS; it is the fundamental design principle.
Embedded Systems — Purpose-Built and Often Difficult to Update
Embedded systems are hardware-software combinations designed to perform a specific function as their sole purpose — a smartwatch tracking heart rate, a television streaming content, a medical device monitoring patient vitals, an industrial controller managing a conveyor belt. The operating system is embedded in the device, often in firmware, and the entire software stack is purpose-built rather than general-purpose.
The security challenge of embedded systems is the update lifecycle. Devices like smart TVs and smartwatches are designed by manufacturers who have update infrastructure and regularly push security patches. But many embedded devices — particularly older industrial equipment, purpose-built appliances, and devices from smaller manufacturers — are difficult or impossible to update after deployment. The firmware is burned into the hardware at manufacture and there is no mechanism to patch it.
For embedded systems that can receive updates, apply them promptly. Manufacturer security patches for embedded devices are relatively rare; when one is released, it typically addresses a significant vulnerability. For embedded systems that cannot be easily updated, the defense shifts to the network level: segment these devices onto their own isolated network segment and deploy a firewall in front of that segment. This limits what the devices can reach and what can reach them, containing the impact if an unpatched device is compromised. The combination of network-level containment and prompt patching when available is the practical hardening strategy for embedded systems.
RTOS — Deterministic Timing Requires Absolute Isolation
A Real-Time Operating System (RTOS) is an operating system designed for applications where the timing of processes is critical — where a task that must complete within 1 millisecond cannot be delayed by 2 milliseconds without causing a failure. RTOS platforms operate on deterministic processing schedules: every process has a guaranteed time window in which it runs, and the scheduler enforces these windows strictly. The applications that require this precision are systems where timing failures have immediate physical consequences: industrial machinery that must respond to a sensor reading within microseconds, automotive anti-lock braking systems that must activate within milliseconds, military targeting systems, and aircraft flight control.
Isolation is non-negotiable for RTOS. The deterministic behavior that makes RTOS valuable for these applications is also the reason it cannot share a network with general-purpose systems. Any network traffic, any process contention, any resource demand from a connected system can introduce timing variability that disrupts the RTOS schedule. Beyond the timing concern, any network connectivity introduces potential attack vectors. An RTOS running an aircraft control system or a nuclear plant safety system cannot be accessible from corporate networks. Network isolation is both a safety requirement and a security control.
Minimum services, maximum simplicity. RTOS hardening follows the principle of minimality: run only the services that the specific application requires, and eliminate everything else. Fewer services means fewer potential vulnerabilities, fewer processes competing for resources, and more predictable system behavior. Where network communication is required — for monitoring data export or configuration management — implement it through a controlled, one-directional path with host-based firewall restrictions enforcing exactly what traffic is permitted.
IoT — Convenience at the Cost of Security
Internet of Things (IoT) devices are the networked devices that manage physical environments: smart thermostats controlling HVAC, networked lighting systems, building access controls, security cameras, industrial sensors, wearable health monitors. The appeal of IoT is operational visibility and remote control. The security problem of IoT is that the manufacturers of HVAC systems, lighting controllers, and industrial sensors are industrial engineers, not security professionals. Their devices frequently ship with weak default passwords, open network services, unencrypted communications, and no plan for long-term security updates.
Change defaults immediately. IoT devices frequently ship with published default credentials — the same password on every unit of the same model, documented in the product manual and on manufacturer websites. These defaults are well known and actively targeted. The Mirai botnet, which generated the largest DDoS attacks in history at the time, primarily compromised IoT devices by connecting with their factory-default credentials. Changing every default password immediately at deployment is the single highest-priority IoT hardening action.
Apply patches quickly. When a security patch is available for an IoT device, the urgency for deployment is high. IoT devices often have known public vulnerabilities — CVEs that describe exactly how to exploit them — and many organizations have thousands of these devices deployed. A patch that is available but not deployed leaves every one of those devices exploitable via a documented, public method. Unlike enterprise servers where patch testing cycles are appropriate, IoT patches should typically be deployed as quickly as possible given the weakness of the underlying platform.
Segment IoT onto its own VLAN. Because IoT devices are difficult to fully secure at the device level — limited management interfaces, infrequent updates, weak default configurations — network-level containment is a critical compensating control. Placing all IoT devices on a dedicated VLAN, isolated from corporate systems, means that if an IoT device is compromised, the attacker's reach is limited to other IoT devices on that segment. They cannot directly pivot to servers, workstations, or other corporate resources. The VLAN boundary enforced by firewall rules ensures that even a fully compromised IoT device is not a stepping stone into the broader network.