ENDPOINT AND MOBILE SECURITY STANDARD

Endpoint Protection · EDR · Device Posture · Mobile Device Management · BYOD

Table of Contents

1. Purpose and Scope
2. Principles
3. Endpoint Classes
4. Baseline Endpoint Protection
5. Endpoint Detection and Response
6. Device Posture
7. Mobile Device Management
8. Bring Your Own Device
9. Transient and Removable Devices
10. Roles and Responsibilities
11. Regulatory and Framework Alignment Summary
12. Document Control

1. Purpose and Scope

The endpoint is where the user meets the estate, and where most intrusions begin. A phishing click, a malicious document, a compromised laptop: the endpoint is the first system an attacker touches and the device from which they reach everything else. The Secure Configuration Baseline Standard hardens endpoints; the Access Management Standard governs who signs in. Neither owns the endpoint as a security surface in its own right. This standard does.

This standard establishes the requirements for endpoint and mobile device security across CERG-managed environments: baseline endpoint protection, endpoint detection and response, the device posture signal other standards depend on, mobile device management, and the terms under which a personally owned device may access in-scope resources.

It applies to every endpoint and mobile device that accesses in-scope resources: owned workstations and laptops, corporate mobile devices, and personally owned devices used under the bring-your-own-device terms in Section 8.

The Endpoint Posture Signal Is Used Everywhere

This standard does more than protect laptops. It produces the device posture signal that the Network Security Standard consumes for zero-trust access decisions, that the Access Management Standard consumes for conditional access, and that remote access depends on. An endpoint estate with no reliable posture signal forces every other standard to fall back to trusting the network or the password alone. Endpoint security is a supplier to the rest of the program, not just a protector of devices.

2. Principles

1. Every endpoint is managed or it has no access. A device that accesses in-scope resources is enrolled in management and meets this standard, or it does not get access. There is no unmanaged-but-trusted category.
2. The endpoint is inventoried. Every endpoint is an asset in the inventory governed by CERG-STD-AM-001. An endpoint not in the inventory is an unmanaged asset and is contained.
3. Posture is checked, not assumed. A device’s compliance with this standard is verified continuously and at the point of access, not assumed because the device was compliant once.
4. Protect, detect, and respond on the device. Endpoints carry preventive controls and a detection-and-response capability. Prevention fails; the endpoint must also be a place where compromise is seen and contained.
5. BYOD is a deliberate, bounded decision. Personal devices may access in-scope resources only under explicit terms that bound what they reach and what the organization controls. BYOD is never the absence of a rule.
6. Loss of a device is not loss of the data. Endpoint data is encrypted and remotely recoverable or erasable, so a lost or stolen device is an inconvenience, not a breach.

3. Endpoint Classes

OT field devices and OT engineering workstations are governed by CERG-STD-OT-001, not this standard. Where an OT engineering workstation is also a transient cyber asset, Section 9 and the OT standard are read together.

4. Baseline Endpoint Protection

Every managed endpoint carries the following at minimum.

1. Secure configuration baseline. The endpoint is configured to the applicable baseline in CERG-STD-CFG-001, and configuration drift is detected and corrected.
2. Disk encryption. Endpoint storage is encrypted at rest per CERG-STD-CR-001. Encryption is enforced by management, not left to the user.
3. Patching. The operating system and installed software are patched against the SLAs in CERG-PRC-VM-001. The endpoint reports its patch state to management.
4. Malware protection. The endpoint runs current malware protection.
5. Host firewall. A host-based firewall is enabled and configured to default-deny inbound, consistent with CERG-STD-NET-001.
6. Application control. Tier-appropriate control over what software may execute. Privileged-access endpoints (Section 4.5) and endpoints handling regulated data enforce allowlisting; standard workstations enforce at minimum a block on known-bad and unsigned execution.
7. Screen lock and authentication. The endpoint enforces an automatic screen lock and authenticates the user per CERG-STD-AC-001.
8. Local administrative rights are restricted. Users do not hold standing local administrator rights on their workstations. Where elevation is needed it is granted just in time and recorded.

4.1 Privileged-Access Endpoints

An endpoint used to administer infrastructure is a high-value target and is hardened beyond the baseline: application allowlisting is mandatory, the device is dedicated to administrative use and not used for email or general browsing, and it is segmented per CERG-STD-NET-001. Administering the estate from a general-purpose daily-use laptop is prohibited.

Standing Local Admin Rights Are a Self-Inflicted Wound

When every user is a local administrator of their own machine, every phishing click runs with administrative privilege, every piece of malware installs cleanly, and the endpoint’s own controls can be disabled by the very user the controls protect. Removing standing local admin rights is one of the highest-value, lowest-cost endpoint controls in existence. CERG mandates it, and grants elevation just in time when a genuine need arises.

5. Endpoint Detection and Response

1. Every managed endpoint runs EDR. An endpoint detection and response capability runs on every workstation, corporate mobile device where supported, and privileged-access endpoint.
2. EDR telemetry reaches the detection platform. EDR telemetry is delivered to the platform governed by CERG-STD-LM-001, so endpoint events are visible alongside the rest of the estate.
3. EDR supports containment. The capability allows a compromised endpoint to be isolated from the network quickly, so a foothold can be contained without physically retrieving the device.
4. EDR tampering is itself an alert. An attempt to disable, uninstall, or evade EDR is a detection signal and is alerted on.
5. CERG feeds, the IR team responds. Consistent with CERG-GOV-OM-001 §3.4, CERG operates the EDR capability and feeds its telemetry and detections to the standing Incident Response team. CERG does not run incident response from this standard.

6. Device Posture

Device posture is the set of facts about an endpoint that other standards use to make access decisions. This standard owns producing it.

1. Posture is defined. A device is in posture when it is enrolled in management, on a supported and patched operating system, encrypted, running current EDR and malware protection, and not flagged with an unresolved high-severity finding.
2. Posture is evaluated continuously and at access. Posture is checked continuously by management and again at the point a device requests access to a resource.
3. Out-of-posture devices lose access. A device that falls out of posture loses access to in-scope resources until it is brought back into posture. The loss of access is automatic, not a manual follow-up.
4. Posture is the signal other standards consume. The posture verdict is the input that CERG-STD-NET-001 uses for zero-trust decisions and that CERG-STD-AC-001 uses for conditional access. This standard is the authoritative producer of that signal.

7. Mobile Device Management

1. Corporate mobile devices are enrolled in mobile device management. Organization-owned phones and tablets are managed: configuration is enforced, security policy is pushed, and compliance is reported.
2. Mobile baseline. A managed mobile device enforces device encryption, a passcode or biometric unlock, automatic lock, current operating system, and a block on installing applications from untrusted sources.
3. Organization data is containerized. Organization email, files, and applications on a mobile device are held in a managed container separable from anything personal on the device.
4. Remote lock and wipe. A managed mobile device can be remotely locked and can have organization data remotely wiped. A lost corporate device is wiped.
5. Jailbroken and rooted devices are blocked. A device whose operating system integrity has been compromised does not access in-scope resources.

8. Bring Your Own Device

BYOD is permitted only under the explicit terms in this section. An organization adopting CERG may decline BYOD entirely; if it permits BYOD, these terms apply.

1. BYOD access is enrolled and bounded. A personal device accessing in-scope resources is enrolled in management scoped to organization data only. The organization manages its container; it does not manage the user’s personal device.
2. The managed container is the boundary. Organization email, files, and applications live in a managed, encrypted container. Organization data does not leave the container onto the personal device.
3. Posture still applies. A BYOD device meets the device posture definition in Section 6 for the managed container. An out-of-posture personal device loses access exactly as a corporate device does.
4. Selective wipe, not full wipe. The organization can wipe the managed container, removing organization data without touching the user’s personal content. Offboarding a user or losing the device triggers a container wipe.
5. What BYOD may not reach. Personal devices do not reach privileged administrative interfaces, OT systems, or, unless an explicit risk acceptance is recorded, regulated data scopes such as CUI. Administrative and regulated access is from managed, organization-owned endpoints.
6. The terms are agreed in writing. A user using BYOD acknowledges the terms: the managed container, the organization’s right to wipe it, and the posture requirements. BYOD without recorded user agreement is not permitted.

BYOD Is a Trade, and the Trade Is Written Down

Bring-your-own-device trades convenience for a controlled reduction in assurance. That trade is acceptable when it is bounded and explicit, and dangerous when it is silent. The failure mode is the personal phone quietly syncing the entire mailbox with no container, no posture check, and no way to wipe it when the employee leaves. CERG permits BYOD only as a written, bounded arrangement: a managed container, a posture requirement, a selective-wipe right, and a clear list of what personal devices may never reach.

9. Transient and Removable Devices

1. Transient devices are controlled before they connect. A device that connects briefly to the estate, a contractor laptop, a maintenance device, is checked for posture before connection or is restricted to an isolated network segment per CERG-STD-NET-001.
2. Removable media is controlled. Use of removable storage is restricted by default. Where permitted, removable media is encrypted and scanned. Endpoints handling regulated data block removable storage unless an exception is recorded.
3. Transient cyber assets in OT scope. A transient device connecting to OT, including for maintenance, is a transient cyber asset and is governed by CERG-STD-OT-001 and NERC-CIP requirements. Section 9 and the OT standard are read together for those devices.

10. Roles and Responsibilities

Roles below are the canonical role names from CERG-GOV-OM-001 §6.1.

11. Regulatory and Framework Alignment Summary

12. Document Control

Revision History

Review Triggers

• Material change to the endpoint estate, mobility model, or BYOD policy
• Revision of NIST 800-124 or relevant NIST 800-53 controls
• A significant endpoint-originated security incident
• Internal audit or regulatory finding affecting endpoint security
• Direction from the CISO

Cyber Engineering owns this document. The Engineering Pillar Leader (Endpoint) is responsible for initiating reviews, managing the revision cycle, and obtaining Governance Pillar Leader approval, with CISO endorsement, for all changes.

Related Documents

Source: standards/CERG-STD-EP-001_Endpoint_and_Mobile_Security_Standard.md · Download .md · View on GitHub