VIEWPOINT: Why frontline computing needs a layered approach 

Jerry Huang Securing frontline computing devices takes more than authentication and endpoint protection.  Australian defence and frontline organisations must also protect sensitive data, manage physical access, and account for devices that operate across different systems and environments. Security therefore depends on how the device is designed, configured, and managed, not just its individual features. The Australian Signals Directorate’s (ASD) September 2026 Information Security Manual (ISM) reinforces the importance of approved equipment configurations, system hardening, physical protection, and lifecycle management. For organisations relying on rugged computing, the challenge is applying these controls to equipment that must also support specialised applications, communications, and operational requirements. A device can offer strong authentication and encryption capabilities and still introduce security risks through its hardware interfaces, connected equipment, or configuration. Product specifications may not reveal these risks, making platform customisation an important consideration. One of the challenges with frontline security is that the controls needed to protect information can also restrict how personnel work. Disabling a port or wireless connection may reduce exposure, but it could also prevent access to essential equipment or communications. The manufacturer’s role is to help resolve those trade-offs at the design and configuration stage, so security requirements don’t become operational constraints in the field. Security starts with how the device will be used Authentication is an essential part of frontline security; however, controlling access to a device does not necessarily protect the information stored on it or restrict how that information can be transferred. Security requirements become more challenging when devices are shared, moved between locations, or left unattended. A device used to access sensitive operational information may need more than biometric authentication or a smart card reader. Storage encryption can help protect data if equipment is lost or stolen, while removable solid-state drives (SSDs) offer a practical way to separate stored information from the computing hardware. However, removing a drive does not automatically make the remaining equipment suitable for another user. Organisations still need procedures for encryption, storage, media handling, and the protection of any other information retained on the device. Firmware-level attacks can compromise a device during startup, potentially bypassing security measures that operate within the operating system. Hardware-backed root-of-trust technologies, including Trusted Platform Module (TPM) 2.0 cryptographic processors, help establish a trusted foundation for system integrity and the protection of encryption keys. Microsoft Secured-core PC architecture takes this further by combining hardware, firmware, and virtualisation-based security controls to protect against threats below the operating system. For defence organisations, this introduces another consideration when evaluating rugged computing: whether the underlying platform can support the security architecture required to protect sensitive information, rather than relying solely on software-based controls. For manufacturers, the starting point is understanding the operating environment, which protections are needed, and how they will affect the task. Configuration can expose gaps beyond the device Hardware interfaces add complexity. Wireless modules, cameras, microphones, and external ports can be essential to a frontline workflow, but their suitability depends on the security environment. A connection required for one application may be unnecessary or restricted in another. This becomes particularly important when rugged computers form part of a wider system. Vehicle docks, external communications equipment, and specialist peripherals can introduce connections that are not present when the device is used independently. As a result, securing the device itself may not address every route through which information can be accessed or transferred. Australian organisations evaluating frontline technology should consider whether the manufacturer can support the required configuration across the complete deployment, including the external systems on which the task depends. Physical security needs to account for device access Frontline equipment is not always used in controlled environments. Rugged computers may be carried between operational locations, installed in vehicles, or deployed in settings where personnel cannot maintain continuous supervision. This creates security risks that office-based equipment may not face. Physical locks, controlled storage, and restricted access to internal components can help reduce these risks. However, organisations handling sensitive information may also need to consider what happens if someone attempts to interfere with the device itself. For example, a customised rugged laptop developed for a military application incorporates chassis intrusion detection that remains active even when the device is powered off. If tampering is detected, the system triggers a motherboard lockout, preventing the computer from booting. While authentication restricts who can use the system, hardware-level protection can help address attempts to physically interfere with it. Both controls serve different purposes and need to be considered as part of the wider security architecture. The ASD’s physical security guidance also addresses the protection of equipment and information in different operating environments, including deployable platforms. For frontline organisations, this makes the way equipment is transported, stored, accessed, and maintained relevant to its overall security. Durability and information security should not be treated as equivalent. A device designed to withstand physical impacts or environmental exposure still requires appropriate controls against unauthorised access and interference. Security must be maintained beyond deployment Device security also changes over time. Equipment may receive firmware updates, undergo repairs, move between operational roles, or be replaced while the wider system remains in service. Each change can affect the approved security configuration. Changes in device ownership or operational use also raise questions about the information left behind. Deleting files or restoring a device to its factory settings does not necessarily make previously stored information unrecoverable. Physical data separation and emergency sanitisation are therefore important considerations for defence organisations managing sensitive information, particularly when equipment is transferred, returned for maintenance, or retired. Dedicated sanitisation capabilities can support these processes. For example, Getac Secure Erase is designed to securely erase data from SSDs to help prevent unauthorised recovery. The practical consideration is whether the available sanitisation method meets the organisation’s information-handling requirements and can be applied consistently throughout the equipment lifecycle. This is particularly relevant where organisations depend on customised hardware or firmware settings. If a device has been configured to restrict particular interfaces or support specialist security controls, a replacement or repaired unit needs to be assessed against those same requirements. Otherwise, previously addressed risks may return. Hardware interfaces, firmware settings, security controls, and any specialist modifications may need to be checked against the approved configuration before equipment returns to service. A device can operate normally after maintenance while no longer meeting the security requirements established for its original deployment. The ASD’s ISM specifically calls for IT equipment to be inspected following maintenance or repairs to confirm that approved configurations remain in place and no unauthorised modifications have been made. This makes post-repair verification an important consideration when evaluating long-term support arrangements. It is important to establish how approved settings will be documented, how replacement equipment will be configured, and whether specialist requirements can continue to be supported as technology changes. A secure configuration at the point of purchase has limited long-term value if it cannot be maintained throughout the device’s working life. Security is an architecture, not a certification Frontline security cannot be established through a single feature or certification. Authentication, data protection, interface controls, physical security, and lifecycle management address different risks. Their effectiveness depends on how they operate together within the broader system. Manufacturers have a role beyond supplying standard security features. The ability to adapt hardware, configure firmware, and develop specialist solutions can help organisations address requirements that would otherwise create deployment constraints or require additional workarounds. It’s important to note that manufacturer-level security features do not replace organisational security policies, system accreditation, or ongoing risk management. A suitable rugged computing platform must support the controls required by the organisation and the conditions in which the equipment will operate. Australian defence and frontline organisations require a complete device configuration that can support the required security controls across its intended operating environment and working life. Procurement teams should assess hardware, connected equipment, data handling, and ongoing support together. The value of a secure rugged computing platform lies in how well those protections fit the task, the wider system, and the risks the organisation needs to manage. Note: Jerry Huang is vice president for global market development at Getac. For Editorial Inquiries Contact: Editor Kym Bergmann at [email protected] For Advertising Inquiries Contact: Group Sales Director Simon Hadfield at [email protected]