Marcus Delaney had twenty minutes between his flight landing in Denver and his rideshare pickup, so he left his laptop bag on the seat next to him at the airport Chili's while he refilled his water bottle twelve feet away. When he turned around, the bag was gone.
Marcus was the senior DevOps engineer at Halloway Fulfillment, a mid-size logistics company that ran warehouse-routing software for eleven regional distribution centers. His laptop wasn't just a laptop. It had a cached VPN session, a browser full of saved credentials, an SSH key with no passphrase, and a local clone of the routing engine's source code — the same code that decided which trucks went where, in what order, carrying how much. The disk wasn't encrypted, because Halloway's build had been imaged two years earlier, before the IT team standardized on full-disk encryption, and nobody had gone back to fix the older fleet.
Within six hours, someone using Marcus's cached VPN session had logged into Halloway's internal network from an IP address in a different country. Within two days, that same access had been used to pull a copy of the routing engine's repository and to create three new privileged accounts inside the warehouse management system — accounts nobody at Halloway had approved, because nobody was watching for that kind of change. By the time Halloway's security team noticed unusual authentication patterns and pulled the plug, the attacker had exfiltrated proprietary routing logic, customer shipment data for four Fortune 500 accounts, and had left a foothold that took three weeks of forensic work to fully eradicate. Halloway's total cost — incident response, legal counsel, customer notification, contract penalties from two clients who invoked security clauses, and the six-figure investment in the endpoint and authentication controls that should have existed in the first place — landed just north of $3.1 million.
Nothing about the Halloway breach involved a novel attack technique. It was an unencrypted laptop, a cached session with no re-authentication requirement, an SSH key without a passphrase, source code sitting on a device with no access logging, and privileged accounts nobody was monitoring. Every one of those gaps maps directly to one of five Annex A controls: 8.1 (user endpoint devices), 8.2 (privileged access rights), 8.3 (information access restriction), 8.4 (access to source code), and 8.5 (secure authentication). This is the cluster of controls I get called in to fix most often after an incident, because they sit exactly at the intersection of "things employees touch every day" and "things attackers target first."
Who this is for and what you'll walk away with
This article is written for the ISMS lead, IT manager, or security engineer who has to operationalize ISO/IEC 27001:2022 Annex A controls 8.1 through 8.5 — not just write policy language, but produce an endpoint security standard that MDM and EDR tooling can actually enforce, an authentication standard that specifies which factors apply to which systems, source-code access rules that a platform engineering team will respect, and access-restriction logic that ties back to the organization's access control policy. I'll cover control 8.2 (privileged access rights) at a summary level here, because it deserves — and gets — its own full treatment in the dedicated deep-dive on privileged access rights management. By the end, you'll have concrete tables you can adapt directly into your Statement of Applicability evidence and your internal standards documentation, a realistic phased rollout plan, and a working sense of what an auditor will actually ask to see rather than just what the control text says on paper.
Why this control cluster punches above its weight
If you've read the ISO 27001 Technological Controls overview, you already know Annex A's technological theme runs from 8.1 to 8.34 and covers everything from endpoint hygiene to cryptography to secure development. Controls 8.1 through 8.5 are the five that sit closest to the individual user — the laptop in their bag, the password (or passkey) they log in with, the folders they can see, the repository they can push to, and the extra privileges some of them carry. In my audit experience across 200-plus organizations, this cluster accounts for a disproportionate share of both audit nonconformities and real-world breach root causes, because it's where policy meets human behavior at the highest frequency. A firewall rule gets set once. A laptop gets carried into a coffee shop every day.
"I tell every client the same thing: your firewall is not what gets you breached anymore. It's the loose combination of an unmanaged laptop, a reused password, and a source code repo nobody restricted access to. That's the trifecta." — Renata Voss, Director of Information Security, Bardwell Analytics
Illustratively, across the audits and incident reviews I've been part of, this cluster tends to account for somewhere in the neighborhood of a third of the technological-controls nonconformities I write up in a typical Stage 2 audit — not because the controls are conceptually difficult, but because they require continuous enforcement across a constantly changing population of devices, accounts, and repositories rather than a one-time configuration. A network segmentation project, once done, largely stays done. An endpoint fleet changes every time someone is hired, a laptop is replaced, or a new SaaS tool is adopted, and each of those events is a fresh opportunity for a gap to open quietly.
The zero-trust lens on this cluster
If you've spent any time around security architecture conversations in the last few years, you've heard "zero trust" applied to everything from network segmentation to cloud workload identity. Stripped of the marketing gloss, zero trust is a design principle: never grant access based on network location or a single prior authentication event; instead, verify identity, device posture, and context continuously, for every request. Controls 8.1 through 8.5 are, in practice, where zero-trust principles get implemented for the ordinary end user, even in organizations that have never formally adopted a "zero trust" program name.
An endpoint that reports its compliance status (patched, encrypted, EDR-active) before it's allowed to authenticate is zero trust applied to 8.1. Authentication that adapts to risk signal rather than trusting a single successful login for the rest of a session is zero trust applied to 8.5. Access restricted to the minimum scope a role needs, re-verified rather than assumed, is zero trust applied to 8.3. You don't need a rebranded program or a new budget line to get the benefit — you need the underlying discipline these five controls already require, applied consistently rather than as isolated point solutions. I've found that framing this cluster to executive stakeholders as "the practical foundation of zero trust you already have to build for certification anyway" is far more persuasive than treating it as a compliance line item, because it reframes the spend as strategic architecture rather than audit overhead.
Control 8.1 — User endpoint devices
What the control requires
Control 8.1 requires that information stored on, or accessible via, user endpoint devices be protected. "User endpoint devices" is deliberately broad — it covers corporate-owned laptops and desktops, mobile phones, tablets, and increasingly personally-owned devices used under a bring-your-own-device (BYOD) arrangement. ISO 27002:2022's guidance for this control focuses on a topic-specific policy for endpoint use, device registration and inventory, configuration hardening, encryption, remote wipe capability, and rules for physical protection when devices leave the office.
The control doesn't mandate a specific technology stack — it doesn't say "you must use Intune" or "you must use Jamf." What it requires is that your organization can demonstrate a deliberate, documented, and enforced approach to protecting information wherever an endpoint device carries it. That distinction matters during audits: an auditor won't ask which mobile device management (MDM) platform you use, but will absolutely ask to see the endpoint policy, the device inventory, and evidence that the policy is actually being enforced rather than just written down.
Endpoint device requirements and evidence
Requirement | What "good" looks like | Evidence an auditor will accept |
|---|---|---|
Topic-specific endpoint policy | Documented rules covering laptops, phones, tablets, BYOD, and loaner devices | Approved policy document with review date and owner |
Full-disk encryption | BitLocker, FileVault, or equivalent enabled by default on all corporate endpoints | MDM compliance report showing encryption status per device |
Device inventory and registration | Every endpoint that touches company data is enrolled and tracked | Live asset inventory export cross-referenced with HR headcount |
Screen lock and session timeout | Auto-lock after a defined idle period (commonly 5–10 minutes) | MDM configuration profile screenshot or policy export |
Remote wipe / selective wipe capability | Ability to remotely wipe corporate data on loss, theft, or offboarding | Test log showing a successful remote wipe exercise |
Malware and endpoint detection tooling | EDR agent installed and reporting on all managed endpoints | EDR console coverage report |
BYOD containerization | Corporate data segregated into a managed container on personal devices | MDM enrollment records and containerization policy |
Patch and OS version compliance | Devices kept within a defined number of versions/patches behind current | Patch compliance dashboard export |
Physical protection guidance | Rules for travel, public Wi-Fi, cable locks, unattended device handling | Training completion records referencing endpoint handling |
Loss/theft reporting procedure | Clear path for employees to report a lost or stolen device immediately | Incident log entries tagged "lost device" |
Halloway's failure was almost a textbook illustration of what happens when three of these rows are unaddressed at once: no enforced encryption baseline across the full device fleet, no remote wipe exercised in practice, and no session timeout on the cached VPN connection. Any one of those alone is a finding. All three together is a breach.
BYOD, mobile, and the "endpoint" that isn't a laptop
Endpoint device management extends beyond corporate laptops. Phones and tablets — company-issued or personally owned — that touch email, cloud file shares, or line-of-business apps are endpoint devices under 8.1's scope. The most common gap I find in mid-market organizations is a mature laptop management program sitting next to an almost entirely unmanaged mobile fleet: employees reading corporate email on personal Android phones with no passcode, no encryption verification, and no way to remotely wipe corporate data if the phone is lost. A mature approach treats mobile the same as desktop — enrollment, minimum OS version, encryption verification, and containerization for BYOD so a wipe command removes corporate data without touching personal photos.
"The moment we started treating phones as endpoints instead of 'just a phone,' our audit findings on 8.1 disappeared. Before that we had a beautiful laptop policy and a mobile blind spot the size of a stadium." — Devon Achebe, IT Operations Manager, Fenwright Insurance Group
MDM, EDR, and zero trust: how the pieces actually fit together
Clients frequently ask me to untangle three acronyms that get used almost interchangeably in vendor marketing but do genuinely different jobs. Mobile device management (MDM) — sometimes bundled into a broader unified endpoint management (UEM) platform — is about configuration and compliance: enforcing encryption, pushing patches, enrolling devices, and enabling remote wipe. Endpoint detection and response (EDR) is about behavior: watching for malicious process activity, lateral movement, and post-compromise indicators, and giving your security team the ability to isolate a device the moment something looks wrong. Zero trust, as covered above, is the architectural principle that ties device compliance and user authentication together at the point of every access request, rather than trusting a device or session indefinitely once it's on the network.
None of the three substitutes for the others, and control 8.1 implicitly expects all three to be present in some form: MDM for the "protect information on the device" half of the control, EDR for the "detect when protection has failed" half, and a zero-trust-aligned access model so that a compromised or non-compliant endpoint can't simply present a valid cached session and walk through the front door — which is precisely the failure mode that turned Marcus Delaney's stolen laptop bag into a network-wide breach at Halloway.
Capability | Primary job | What it does NOT do |
|---|---|---|
MDM / UEM | Configuration enforcement, encryption verification, patch compliance, remote wipe | Detect active malicious behavior on a compliant device |
EDR | Behavioral detection, threat hunting, isolation of compromised endpoints | Enforce baseline configuration or encryption policy |
Zero-trust access model | Continuous verification of identity + device posture before granting access | Replace the need for MDM or EDR — it depends on both for signal |
I recommend clients budget for all three as a package rather than sequencing them years apart; an EDR agent with nothing enforcing baseline configuration is watching a house with the doors unlocked, and an MDM platform with no behavioral detection layered on top will faithfully report "fully encrypted, fully patched" right up until the moment malware executes on a perfectly compliant device.
Control 8.2 — Privileged access rights (summary)
What the control requires, briefly
Control 8.2 requires that the allocation and use of privileged access rights be restricted and managed. Privileged access — domain admin, root, database superuser, cloud IAM admin roles, and similar elevated permissions — is the access an attacker wants most, because it collapses the distance between "got a foothold" and "own the environment." At a summary level, the control expects you to: maintain a formal process for granting and revoking privileged access, apply the principle of least privilege by default, require separate accounts for privileged versus everyday activity, log and review privileged sessions, and time-box privileged grants wherever practical rather than leaving them standing indefinitely.
In the Halloway case, the attacker's ability to create three new privileged accounts inside the warehouse management system with no approval workflow and no alerting is a direct 8.2 failure layered on top of the 8.1 failure that got them in the door. I'm intentionally not going deep into privileged access management architecture here — just-in-time elevation, privileged access workstations, session recording, and break-glass account design all deserve full treatment, and they get it in the companion deep-dive on privileged access rights management. If your organization is building or auditing a PAM program, that's the article to work from; treat this section as the map reference that tells you where 8.2 sits relative to its four neighboring controls.
8.2 at a glance
Element | Summary requirement | Where to go deeper |
|---|---|---|
Privileged account inventory | Every privileged account identified, owned, and reviewed on a defined cycle | Dedicated 8.2 deep-dive |
Least privilege | Privileged rights granted only for the scope and duration needed | Dedicated 8.2 deep-dive |
Separate accounts | Named individuals use distinct standard and privileged accounts | Dedicated 8.2 deep-dive |
Session monitoring | Privileged sessions logged and periodically reviewed | Dedicated 8.2 deep-dive |
Emergency/break-glass access | Documented, audited process for emergency elevated access | Dedicated 8.2 deep-dive |
Control 8.3 — Information access restriction
What the control requires
Control 8.3 requires that access to information and other associated assets be restricted in accordance with the organization's access control policy. This is the control that operationalizes need-to-know: it's not enough to have an access control policy on paper (that's the domain of controls 5.15 through 5.18 — access control, identity management, authentication information, and access rights) — you need to show that access to specific systems, applications, and data sets is actually restricted to the people who need it, using mechanisms appropriate to the sensitivity of what's being protected.
ISO 27002:2022 guidance for 8.3 points to techniques like menu-driven restrictions, role-based access control, data classification-driven permissions, controlling read/write/delete/execute rights individually, restricting output (screen, print, export) where sensitive data is involved, and physically or logically isolating especially sensitive systems. The thread connecting all of it: access should be restricted by default and expanded deliberately, not the reverse.
Information access restriction requirements and evidence
Requirement | What "good" looks like | Evidence an auditor will accept |
|---|---|---|
Access mapped to classification | Higher-classified data has narrower, more tightly controlled access | Data classification scheme cross-referenced with access control lists |
Role-based access control (RBAC) | Access granted via defined roles, not ad hoc individual grants | RBAC role catalog and assignment log |
Least privilege by default | New accounts start with minimum access, expanded only on justified request | Access request tickets showing business justification |
Segregation of duties | Conflicting functions (e.g., payment initiation and approval) split across roles | Segregation-of-duties matrix reviewed by internal audit |
Periodic access reviews | Manager or data owner recertifies access on a set cadence (commonly quarterly) | Signed-off access review reports |
Output restriction | Controls on printing, exporting, or screen-sharing sensitive data where warranted | DLP or export-control policy and logs |
Access revocation on role change | Access automatically adjusted when someone changes roles or leaves | Joiner-mover-leaver process documentation and sample tickets |
System-level isolation for sensitive assets | Especially sensitive systems segmented from general user population | Network segmentation diagram and firewall rule review |
The connective tissue between 8.3 and the organizational access controls is worth being explicit about: 5.15 sets the policy ("who gets access to what, and how it's decided"), 5.16 governs how identities are established and managed, 5.17 governs how authentication information (passwords, tokens, keys) is issued and protected, and 5.18 governs the lifecycle of access rights themselves — granting, reviewing, and revoking. Control 8.3 is where all four of those become concrete: the actual technical restriction applied to an actual system. If you haven't already, it's worth reading the dedicated piece on access control policy under controls 5.15 through 5.18 alongside this one, because auditors routinely test both halves in the same interview.
"Auditors love to ask, 'show me someone who left the company two months ago and show me their access today.' If that answer takes more than five minutes to produce, you have an 8.3 and 5.18 problem at the same time." — Priya Nakamura, Lead ISO 27001 Auditor, Alderbrook Certification Partners
Control 8.4 — Access to source code
What the control requires
Control 8.4 requires that read and write access to source code, development tools, and software libraries be appropriately managed to prevent the introduction of unauthorized functionality and to avoid unintentional or malicious changes, and to maintain the confidentiality of valuable intellectual property. This control sits at the boundary between access management and secure development — it's less about the software development lifecycle process itself (that territory belongs to the secure development controls in the 8.25–8.31 range) and more about who is allowed to see, pull, and push code in the first place.
Source code is one of the highest-value assets many organizations hold, and it's routinely under-protected relative to its worth. I've walked into engineering organizations where the customer database has field-level encryption and a strict access review cycle, while the source code repository containing the proprietary algorithm that makes the product valuable is browsable by every employee with a company GitHub seat, including sales and marketing. Halloway's routing engine was exactly this kind of asset: unique intellectual property, wide internal access, and — critically — accessible from an unmanaged endpoint with no additional authentication barrier.
Source code access control requirements and evidence
Requirement | What "good" looks like | Evidence an auditor will accept |
|---|---|---|
Repository access restricted by role | Only engineers actively working on a codebase have read/write access | Repository access control list mapped to team rosters |
Separate read vs. write permissions | Contributors need explicit write/merge rights beyond read access | Branch protection and permission configuration export |
MFA required for source code systems | No repository or CI/CD login without a second factor | SSO/MFA enforcement policy for the source control platform |
Code review before merge | No code reaches production branches without independent review | Pull request history showing required approvals |
Segregation of dev, test, and production | Source code and build artifacts kept separate from live environments | Environment architecture diagram and access matrix |
Library and dependency management | Approved list of third-party libraries; unauthorized packages blocked | Software composition analysis (SCA) scan reports |
Audit logging on repositories | All clone, pull, push, and permission-change events logged | Repository audit log export |
Offboarding removes repository access immediately | Access revoked same day as termination, not at next cleanup cycle | Joiner-mover-leaver ticket with timestamped revocation |
Source code encryption at rest | Repositories and build artifacts stored encrypted | Storage/repository platform encryption configuration |
A useful practical anchor here: if your organization is contemplating outsourced development, or if third parties have any access to your source code, the access restrictions in this table need to extend contractually to those parties as well — reviewed the same way, revoked the same way, logged the same way.
"We treat our source code repositories like we treat production databases now — MFA-gated, logged, reviewed quarterly. It took one contractor account that should have been disabled six months earlier for us to take it that seriously." — Tomas Bergstrom, VP of Engineering, Calloway Vector Systems
Control 8.5 — Secure authentication
What the control requires
Control 8.5 requires that secure authentication technologies and procedures be implemented based on information access restrictions and the access control policy. In plain terms: the strength of your authentication mechanism should scale with the sensitivity of what it's protecting, and that scaling should be a deliberate decision tied back to your access control policy rather than an accident of whatever the default login screen happened to ship with.
ISO 27002:2022 guidance calls out several practices that will be familiar to any practitioner: multi-factor authentication (MFA) for sensitive or higher-risk access, disabling authentication mechanisms that are no longer secure (legacy protocols, unsalted password hashes, SMS-only second factors where stronger options exist), limiting the number of failed authentication attempts, logging authentication events for monitoring, and — increasingly — the use of passwordless and phishing-resistant methods like FIDO2 security keys and platform passkeys.
Secure authentication requirements and evidence
Requirement | What "good" looks like | Evidence an auditor will accept |
|---|---|---|
MFA on all remote and privileged access | No VPN, SSO, or admin login without a second factor | Identity provider configuration showing enforced MFA |
Risk-based / adaptive authentication | Step-up authentication triggered by anomalous location, device, or behavior | Conditional access policy export |
Strong password or passphrase policy | Length-based policy aligned with current guidance, not arbitrary complexity rules | Password policy configuration and awareness materials |
Account lockout / throttling | Failed login attempts are capped and monitored | Authentication log showing lockout events |
Passwordless / phishing-resistant options | FIDO2 keys or platform passkeys available for high-risk roles | Identity provider passkey enrollment report |
Authentication event logging | Successful and failed logins logged centrally | SIEM query showing authentication event ingestion |
Session timeout and re-authentication | Sessions expire and require re-authentication after a defined period | Session policy configuration |
Deprecation of legacy authentication protocols | Basic auth, unencrypted LDAP, and similar disabled | Configuration change record disabling legacy protocols |
Secrets management for service accounts | API keys and service credentials stored in a managed vault, rotated regularly | Secrets manager access policy and rotation logs |
MFA factor types and when to require them
Factor type | Examples | Strength | Best used for |
|---|---|---|---|
Something you know | Password, PIN, security question | Weakest alone | Baseline factor, never sole control for sensitive access |
Something you have (OTP) | SMS code, authenticator app TOTP | Moderate | General workforce MFA where phishing-resistant options aren't yet deployed |
Something you have (hardware) | FIDO2 security key, smart card | Strong, phishing-resistant | Privileged accounts, source code systems, admin consoles |
Something you are | Fingerprint, face recognition (as local device unlock, paired with a key) | Strong when bound to device | Passwordless flows on managed endpoints |
Passkey / platform credential | Synced or device-bound FIDO2 credential | Strong, phishing-resistant | General workforce login as passwordless matures organization-wide |
Push notification with number matching | Authenticator app approval requiring a displayed code | Moderate-strong | VPN and SSO login where hardware keys aren't yet issued |
The step-up principle is the practical heart of 8.5: not every login needs the same friction, but every login needs friction appropriate to what it unlocks. A marketing employee reading the company intranet from their usual laptop, at their usual hours, from their usual location, is a low-risk event. The same employee's credentials being used to log into the payroll system from a new device in a new country at 3 a.m. is a different risk profile entirely, and the authentication mechanism should respond accordingly.
flowchart TD
A[Login attempt] --> B{Known device and location?}
B -- Yes --> C{Accessing standard resource?}
B -- No --> D[Require step-up authentication]
C -- Yes --> E[Standard MFA: password + TOTP/push]
C -- No, privileged or sensitive resource --> D
D --> F{Phishing-resistant factor available?}
F -- Yes --> G[Require FIDO2 key or passkey]
F -- No --> H[Require secondary approval + notify security team]
E --> I[Grant session, log event]
G --> I
H --> I
I --> J{Session anomaly detected mid-session?}
J -- Yes --> D
J -- No --> K[Session continues until timeout]"Step-up authentication is the single highest-leverage control we've deployed in three years. It costs almost nothing to configure in a modern identity provider, and it turns 'stolen password' from a breach into a non-event." — Janelle Osei, CISO, Merrow Financial Technologies
Passwordless authentication and secrets management
Two threads under control 8.5 deserve separate attention because they're where I see the most implementation confusion: passwordless authentication for people, and secrets management for machines.
Passwordless authentication — FIDO2 security keys and platform passkeys — isn't just MFA with an extra step removed. It changes the underlying trust model. A traditional password-plus-OTP flow still depends on a shared secret (the password) that can be phished, guessed, or leaked in a breach dump; the OTP adds friction for an attacker but doesn't eliminate the underlying weakness. A passkey uses public-key cryptography bound to the specific website or application it was registered against, which means it simply cannot be entered into a convincing-looking phishing page the way a password and OTP code can. That's what "phishing-resistant" means in the tables above, and it's why I push privileged accounts and source code systems toward hardware keys or passkeys first, then extend passwordless to the general workforce as the organization's identity provider and device fleet mature enough to support it broadly. The rollout order matters: start with the smallest, highest-risk population (admins, engineers with production or repository access), prove out the user experience and recovery process (lost key, new device), then expand.
Secrets management is the parallel problem for service accounts, API keys, and machine-to-machine authentication — and it's a control 8.5 concern that's easy to overlook because "secure authentication" instinctively reads as being about humans. Every organization I've assessed has, somewhere, a shared service account credential sitting in a configuration file, a CI/CD pipeline variable, or — worse — a Slack message from eighteen months ago. The fix is a managed secrets vault: centrally stored, access-logged, automatically rotated credentials that applications retrieve programmatically rather than developers copying into config files by hand. Rotation matters as much as storage — a secret that's been sitting unrotated for two years is a secret that's had two years of exposure surface across every laptop, repository, and log file it ever touched.
Secrets management practice | Why it matters | Common failure mode |
|---|---|---|
Centralized vault (not config files or code) | Removes secrets from source code and unmanaged locations | Secrets committed to source code repositories, sometimes years earlier and never rotated out |
Automatic rotation on a defined schedule | Limits exposure window if a secret leaks undetected | Rotation only happens manually, and manual means "rarely" |
Per-service, non-shared credentials | Limits blast radius if one service account is compromised | Multiple applications sharing one "convenient" service account |
Access logging on secret retrieval | Creates an audit trail of which system pulled which secret, when | Vault deployed but retrieval logging never reviewed |
Building the endpoint security standard
An endpoint security standard is the document that turns control 8.1 from an audit checkbox into something IT can actually execute against day to day. It should be specific enough that a technician provisioning a new laptop knows exactly what settings to apply, and specific enough that an auditor can trace every control back to a configuration setting.
Standard element | Minimum baseline | Elevated baseline (finance, engineering, execs) |
|---|---|---|
Disk encryption | Full-disk encryption enabled, key escrowed centrally | Same, plus hardware-backed key storage (TPM) verified |
OS patching | Critical patches within 14 days | Critical patches within 7 days |
EDR coverage | Agent installed, reporting to central console | Same, plus enhanced behavioral monitoring enabled |
Screen lock timeout | 10 minutes | 5 minutes |
Local admin rights | Removed by default; time-boxed elevation on request | Removed by default; no standing local admin under any role |
USB and removable media | Restricted to approved, encrypted devices | Blocked entirely except by documented exception |
VPN/remote access | MFA required, session timeout enforced | MFA with phishing-resistant factor required |
Application allow-listing | Baseline OS and productivity apps only | Strict allow-list with change-controlled exceptions |
Loss/theft response | Remote wipe within 4 hours of report | Remote wipe within 1 hour of report |
BYOD eligibility | Permitted for email/calendar via containerized app | Not permitted; corporate-owned device required |
Standards like this only work if they're versioned, owned, and reviewed — treat this table as the skeleton, not the finished document, and assign a named owner (typically the IT or infrastructure lead) responsible for keeping it current as your MDM and EDR tooling evolve.
Building the authentication standard
The authentication standard is the 8.5 counterpart: it specifies exactly which authentication mechanism is required for which category of system, so that "secure authentication" isn't left to individual application owners to interpret inconsistently.
System category | Minimum authentication requirement | Session/re-auth rule |
|---|---|---|
General SaaS / productivity apps (SSO-federated) | SSO with TOTP or push MFA | Re-authenticate every 12–24 hours |
VPN / remote network access | SSO with MFA; phishing-resistant factor preferred | Session timeout at 8 hours or on network change |
Cloud infrastructure admin consoles | Phishing-resistant MFA (FIDO2/passkey) mandatory | Re-authenticate for privileged actions; session capped at 1 hour |
Source code repositories and CI/CD | MFA mandatory; hardware key for maintainers | Token-based access with rotation; no standing sessions |
Financial / payment systems | Phishing-resistant MFA mandatory; dual control on transactions | Re-authenticate per transaction above defined threshold |
Customer-facing portals | Password + optional MFA; mandatory MFA for account changes | Session timeout at 30 minutes idle |
Service/machine accounts | Managed secrets vault, no shared credentials, automatic rotation | Credentials rotated on a fixed schedule, no manual reuse |
Effort and cost by organization size
One question I get in nearly every scoping conversation is some version of "how much is this actually going to cost us." The honest answer depends heavily on how much of the underlying identity and endpoint tooling already exists versus needs to be procured, but the relative pattern across organization sizes is consistent enough to be a useful planning anchor.
Organization size | Typical starting gap | Rough effort to close 8.1–8.5 gaps | Where the cost concentrates |
|---|---|---|---|
Small (under 100 endpoints) | No MDM, inconsistent MFA, informal repository access | 4–8 weeks, largely internal IT time | MDM/UEM licensing, identity provider MFA tier upgrade |
Mid-size (100–1,000 endpoints) | Partial MDM coverage, MFA on some but not all systems, no formal access reviews | 2–4 months, IT plus a part-time security/compliance owner | Phishing-resistant hardware keys for privileged users, access review tooling |
Large / multi-site (1,000+ endpoints) | Fragmented tooling across business units, legacy authentication protocols still in use, decentralized repository ownership | 6–12 months, dedicated project team | Consolidating identity providers, retiring legacy protocols, org-wide passkey rollout |
Smaller organizations often over-estimate this cost because they assume they need enterprise-grade tooling from day one; in practice, most cloud-native identity providers and MDM platforms now bundle MFA and device compliance features into tiers that a 50-person company can afford without a large capital outlay. The larger and more fragmented the environment, the more the cost shifts from tooling licenses toward the labor of consolidation — fewer new purchases, more untangling of what already exists across business units that grew up with different standards.
Source code access control patterns worth adopting
Beyond the requirements table above, a few patterns consistently separate organizations that pass 8.4 cleanly from those that scramble to produce evidence:
Team-scoped repository access rather than organization-wide default read access. Most source control platforms default new repositories to visible-by-everyone; that default should be flipped during platform configuration, not left as a policy exception to be caught in audit.
Signed commits for anything touching production-critical code paths, so code provenance is verifiable independent of repository access logs.
Dependency pinning and SCA scanning so that "library access" isn't a blind spot — a compromised or malicious open-source package is functionally the same risk as an unauthorized code change.
Time-boxed contractor and third-party access, expiring automatically rather than relying on someone remembering to revoke it.
Separate credentials for CI/CD service accounts, never a developer's personal credentials, so a person leaving the company doesn't silently break — or worse, leave standing access inside — the build pipeline.
Access-restriction patterns across 8.3
Three patterns come up again and again when I help clients operationalize 8.3 in a way that survives both a real attacker and a real auditor:
Role-based access control (RBAC) ties permissions to job function rather than individual identity, which makes access reviews tractable — you're recertifying a manageable number of roles rather than auditing every individual grant from scratch. Attribute-based access control (ABAC) goes further, layering conditions like data classification, device compliance status, and location on top of role, which is particularly useful for organizations with complex regulatory data (health records, payment card data, government contracts). Need-to-know segmentation — physically or logically isolating especially sensitive systems from the general user population, sometimes down to a dedicated network segment or a separate identity tenant — is the pattern I recommend for the small number of systems (source code for the core product, the HR and payroll platform, the customer data warehouse) that represent outsized risk if broadly accessible.
Pattern | Best fit | Common pitfall |
|---|---|---|
Role-based access control (RBAC) | Organizations with well-defined, stable job functions | Role sprawl — too many overlapping roles created ad hoc |
Attribute-based access control (ABAC) | Complex regulatory environments, dynamic risk conditions | Policy complexity outpaces the team's ability to maintain it |
Need-to-know segmentation | High-value assets: source code, HR/payroll, customer data | Segmentation exists on paper but isn't enforced at the network/IAM layer |
Metrics worth tracking once the controls are live
Implementing the standards above is the first half of the job; the second half is proving, on an ongoing basis, that they're holding. A small set of metrics, reviewed monthly by whoever owns the ISMS, catches drift long before it becomes an audit finding or an incident.
Metric | Target | Why it matters |
|---|---|---|
Percentage of managed endpoints with verified encryption | 100% | Any gap here is a direct 8.1 nonconformity and a breach-multiplier if a device is lost |
Percentage of remote/privileged logins with MFA enforced | 100% | Measures whether the authentication standard is actually enforced, not just documented |
Average time to revoke access after termination | Under 24 hours | Direct proxy for how well joiner-mover-leaver process supports 8.3 and 8.4 |
Number of standing (non-expiring) privileged grants | Trending to zero | Indicates whether time-boxed privileged access is a real practice or a policy aspiration |
Source code repositories with default org-wide read access | Zero | Flags configuration drift back toward the insecure platform default |
Percentage of workforce enrolled in phishing-resistant MFA | Increasing quarter over quarter | Tracks progress on the passwordless rollout rather than treating it as a one-time project |
Dashboards built around metrics like these give the ISMS lead something concrete to bring to management review meetings under Clause 9, and they turn "we think our controls are working" into "here's the data showing our controls are working," which is a categorically stronger position in front of both an auditor and a board.
"The quarter we started reporting encryption coverage and MFA enforcement as hard percentages instead of a status update in a slide, our board stopped asking whether we were 'on top of security' and started asking why one metric hadn't hit 100% yet. That's a much better conversation to be having." — Marcus Reilly, VP of IT, Coldbrook Manufacturing Group
Common mistakes I see across this control cluster
Mistake | Why it happens | Fix |
|---|---|---|
Encryption enforced only on newer device images | Fleet imaged in waves; older devices never revisited | Run a fleet-wide compliance sweep, not just new-device provisioning |
MFA enforced on SSO but not on legacy/direct logins | Shadow IT and legacy apps sit outside the SSO umbrella | Inventory all authentication endpoints, not just the identity provider |
Source code repos default to org-wide visibility | Platform default, never revisited | Flip default to team-scoped access during initial configuration |
Privileged accounts never expire | Convenience during a project, forgotten afterward | Time-box every privileged grant with automatic expiry |
BYOD phones read corporate email with no containerization | Rapid mobile adoption outpaced MDM policy | Extend MDM/containerization policy to all mobile endpoints before enabling mobile email |
Access reviews are a rubber stamp | Manager approves without actually checking the list | Require line-item justification, not a blanket sign-off, for review completion |
Step-up authentication rules only exist in a slide deck | Policy written but never configured in the identity provider | Configure and test conditional access rules, then keep the policy as documentation of what's already live |
Password policy still mandates complexity over length | Legacy policy inherited from pre-2020 guidance | Move to passphrase-length policy with breached-password screening |
What a Stage 2 auditor actually asks to see
Reading a control's requirements is one thing; sitting across from an auditor who's testing whether you've actually implemented it is another. Over 200-plus audits, I've noticed the questions for this cluster follow a predictable pattern — auditors sample specific people and specific systems rather than accepting a policy document at face value, because 8.1 through 8.5 are exactly the controls where "the policy says X" and "the system actually enforces X" most often diverge.
Control | Typical auditor question | What they're really testing |
|---|---|---|
8.1 | "Pick three laptops from the inventory at random — show me encryption status for each, right now." | Whether the endpoint inventory is current and encryption is enforced fleet-wide, not just on a sample the organization pre-selected |
8.2 | "Show me every account with domain admin rights and explain why each one needs it." | Whether privileged access has actually been reviewed recently, or whether the list has simply accumulated over time |
8.3 | "Find me someone who changed roles in the last six months — show me their access before and after." | Whether access adjusts with role change in practice, not just in the joiner-mover-leaver procedure document |
8.4 | "Show me who has write access to your primary product repository, and tell me the last time that list was reviewed." | Whether source code access is actively managed or was set once at repository creation and never revisited |
8.5 | "Log into the VPN in front of me." | Whether MFA is actually enforced at the point of access, not just described as a requirement in the authentication standard |
The organizations that sail through these questions are, without exception, the ones that treat this cluster as a living operational program with current evidence on tap — not a folder of policies produced once for the initial certification audit and never touched again.
Roles and responsibilities: who owns this cluster
One of the fastest ways this control cluster stalls is ambiguous ownership — IT assumes security owns the authentication standard, security assumes IT owns endpoint enforcement, and engineering leadership assumes someone else is watching repository access. A short RACI (Responsible, Accountable, Consulted, Informed) breakdown, agreed once and referenced repeatedly, closes that gap faster than any policy rewrite.
Activity | IT / Infrastructure | Security / ISMS lead | Engineering leadership | HR |
|---|---|---|---|---|
Endpoint standard (8.1) enforcement | Responsible | Accountable | Consulted | Informed |
Privileged access reviews (8.2) | Consulted | Accountable | Responsible (for eng systems) | Informed |
Access restriction reviews (8.3) | Responsible | Accountable | Consulted | Consulted |
Source code access control (8.4) | Consulted | Accountable | Responsible | Informed |
Authentication standard (8.5) | Responsible | Accountable | Consulted | Informed |
Joiner-mover-leaver revocation | Responsible | Accountable | Consulted | Responsible (trigger) |
I recommend making the security or ISMS lead accountable across the board — not because they should do the hands-on configuration, but because they're the role best positioned to see all five controls as a connected system rather than five departmental to-do items. Without a single accountable owner, it's common for 8.1 to be fully mature while 8.4 is untouched, simply because no one role's job description covered source code repository governance until an audit or incident forced the question.
Case study one: the stolen laptop that became a $3.1 million incident
I opened this article with Halloway Fulfillment's story because it's one of the cleanest illustrations I've worked on of how controls 8.1, 8.3, and 8.5 failing together compounds far faster than any one gap alone. Halloway's remediation, once the incident response phase closed, took four months and included: full-disk encryption enforced fleet-wide with a 30-day compliance deadline, MFA with phishing-resistant hardware keys mandated for VPN and source control access, a formal endpoint loss/theft reporting procedure with a one-hour remote-wipe SLA, and a complete rebuild of the warehouse management system's privileged account inventory. Eighteen months later, Halloway passed its ISO 27001 certification audit with zero major nonconformities against the technological controls theme, and — more importantly to their leadership — their cyber insurance premium dropped 22% at renewal once the insurer reviewed the new control set.
Case study two: credential stuffing at a regional bank
A regional bank client (I'll call them Northgate Community Bank, at their request for anonymity) came to me after a credential-stuffing campaign — attackers using passwords leaked from unrelated breaches to attempt logins across thousands of customer and employee accounts — succeeded against fourteen employee accounts that had reused passwords from personal accounts. None of those fourteen accounts had MFA enabled, because Northgate's MFA rollout had been "in progress" for over a year, prioritized by convenience rather than by risk. Two of the compromised accounts had access to the core banking administration console. The bank caught the intrusion within eighteen hours because of anomaly detection on login geography, but the incident forced an emergency board briefing and a costly external forensic review to confirm no customer funds had moved.
Northgate's fix was direct: mandatory phishing-resistant MFA for every account with administrative console access, completed within three weeks under executive mandate, followed by a phased rollout of passkeys to the full employee population over the following quarter. Failed login attempt thresholds were tightened, and breached-password screening was added at password creation. Northgate's next penetration test, run eight months later, found the credential-stuffing attack path fully closed — the tester's stolen-credential simulation was blocked at the second factor on every attempt.
Case study three: the exposed repository
A software vendor client — a 90-person SaaS company building supply-chain forecasting tools — discovered during a routine security review that a former contractor's personal GitHub account still had read access to three private repositories, including the core forecasting algorithm, eleven months after the contract ended. Nobody had noticed because repository access wasn't part of the standard offboarding checklist; it lived in a separate system the IT team didn't own. There was no evidence the access had been misused, but the company couldn't prove that either, because repository audit logging had only been enabled four months earlier.
The fix became the template I now recommend to every engineering-heavy client: repository access folded explicitly into the joiner-mover-leaver process with same-day revocation, MFA mandated for the source control platform, audit logging enabled and retained for twelve months, and a quarterly access recertification specifically for source code repositories, reviewed by engineering leads rather than HR. The company's next customer security questionnaire — increasingly common in SaaS vendor due diligence — went from a multi-week back-and-forth to a same-day pass, because they finally had documented evidence rather than a verbal assurance.
Case study outcomes at a glance
Three very different organizations, three very different failure points inside the same five-control cluster, and three remediation programs that shared the same underlying pattern: close the gap, then prove it with evidence rather than assurance.
Organization | Root cause control gap | Estimated impact before fix | Outcome after remediation |
|---|---|---|---|
Halloway Fulfillment | 8.1 (unencrypted endpoint) + 8.5 (no session timeout/MFA) | ~$3.1M total incident cost | Zero major nonconformities at next audit; 22% cyber insurance premium reduction |
Northgate Community Bank | 8.5 (no MFA on admin console access) | Emergency board briefing; external forensic review cost | Credential-stuffing attack path fully closed in next penetration test |
Supply-chain SaaS vendor | 8.4 (source code access not revoked post-offboarding) | Multi-week delays on customer security questionnaires | Same-day questionnaire turnaround; clean quarterly repository recertification |
How this cluster maps across other frameworks
If your organization is managing more than one compliance framework — which is the norm rather than the exception for most of my clients — it's worth knowing where 8.1 through 8.5 line up elsewhere, both to avoid duplicate work and to speak fluently in whichever framework a given stakeholder cares about.
Framework | Where this control cluster shows up |
|---|---|
SOC 2 | Logical access controls under the Security (Common Criteria) category, particularly CC6 — the criteria that address restricting logical access and authenticating users |
NIST Cybersecurity Framework | Protect function, Identity Management and Access Control category (PR.AC) |
PCI DSS | Requirement 8 — identify users and authenticate access to system components |
None of these mappings make ISO 27001 certification a substitute for SOC 2 attestation, NIST CSF alignment, or PCI DSS compliance — they're related but separately assessed frameworks, and I'd caution any client against telling a customer or regulator "we're ISO 27001 certified, so we're PCI compliant." What the mapping does buy you is efficiency: the evidence you build for 8.1–8.5 — endpoint inventories, MFA configuration exports, access review logs — is largely the same evidence a SOC 2 auditor or a PCI QSA will ask for, so build it once, and reuse it across frameworks.
A 90-day implementation roadmap
Clients rarely need to be convinced that these five controls matter; what they need is a realistic sequence that doesn't require a year-long project before showing any measurable risk reduction. This is the phasing I use most often, assuming a mid-size organization with an existing but incomplete MDM and identity provider footprint.
Phase | Timeframe | Priority actions |
|---|---|---|
Phase 1: Stop the bleeding | Days 1–30 | Enforce MFA on all remote access and all privileged/admin accounts; run a fleet-wide encryption compliance sweep and remediate gaps; fold repository access into the offboarding checklist with same-day revocation |
Phase 2: Standardize | Days 31–60 | Publish the endpoint security standard and authentication standard as approved documents; extend MDM enrollment and containerization to the full mobile fleet; deploy phishing-resistant MFA for source code and cloud admin access |
Phase 3: Operationalize | Days 61–90 | Launch quarterly access recertification for privileged and source code access; enable and centralize authentication and repository audit logging; run a tabletop exercise simulating a lost device and a compromised credential to validate response times |
Organizations that follow roughly this sequence typically walk into their next internal audit with the majority of 8.1–8.5 evidence already in hand, rather than scrambling to produce it in the weeks before an external audit visit.
What a nonconformity against this cluster actually reads like
It helps to see the language an auditor writes down when one of these controls fails, because it makes the abstract requirement concrete and gives you a template for what your own internal audit findings should look like before an external auditor ever gets the chance to write them.
Control | Example nonconformity wording | Typical classification |
|---|---|---|
8.1 | "Sample of 5 laptops reviewed; 2 of 5 did not have full-disk encryption enabled, contrary to the documented endpoint security standard." | Minor (isolated) or Major (if fleet-wide) |
8.2 | "Three privileged accounts identified with no documented business justification and no evidence of periodic review." | Major |
8.3 | "Access review for Q2 was not completed; no evidence of manager sign-off for the finance system access list." | Minor |
8.4 | "Former contractor retained read access to the primary source code repository 11 months after contract termination." | Major |
8.5 | "MFA is documented as mandatory in the authentication standard but was not enforced for VPN access at the time of testing." | Major |
Notice the pattern: nonconformities in this cluster are rarely about the policy wording being wrong. They're almost always about evidence not matching practice — a document saying one thing while the actual system, account list, or configuration says another. That's the single most useful thing to internalize from this whole article: write the standard, then go verify, with your own eyes, that the systems actually do what the standard says, before an auditor does it for you.
The strategic close: turning five controls into a trust asset
It's easy to treat controls 8.1 through 8.5 as compliance overhead — five more boxes to check before an auditor shows up. I'd push back on that framing every time a client hands it to me. Endpoint security and authentication maturity are increasingly things customers ask about directly, in security questionnaires, in procurement reviews, and in contract negotiations, well before ISO 27001 certification ever enters the conversation. An organization that can produce, in minutes, an endpoint inventory with encryption status, an MFA enforcement report, and a source code access recertification is an organization that closes enterprise deals faster, negotiates better cyber insurance terms, and recovers from an incident — because incidents still happen, even in mature programs — in days instead of months.
The five controls in this article are also, not coincidentally, the ones with the clearest, fastest path from "gap" to "closed" of anything in Annex A. You don't need a multi-year architecture overhaul to enforce disk encryption fleet-wide, mandate MFA on privileged accounts, or fold repository access into your offboarding checklist. Most of what's in the tables above is achievable in a single quarter with existing tooling. That combination — high risk reduction, low implementation cost, fast time-to-value — is exactly why this cluster is where I tell clients to start if they're building their Statement of Applicability and looking for early wins that build momentum toward certification.
If you're building out your endpoint and authentication standards from scratch, our Information Security Policy Template gives you a structured starting point rather than a blank page, and our Annex A — All 93 Controls at a Glance cheat sheet keeps the full control set in view while you work through this cluster in detail. If you're not yet sure where your gaps sit across 8.1 through 8.5, run our ISO 27001 Gap Analysis Tool against your current environment before you draft a single policy line — it'll save you from writing standards for controls you've already substantially met, and from missing the ones you haven't. And if you're assembling your mandatory documentation set for certification, our ISO 27001 Mandatory Documents Checklist tells you exactly which of these standards needs to exist in writing versus which just needs to be demonstrable in practice. For teams building their full implementation roadmap, our Complete ISO 27001 Implementation Guide eBook walks through sequencing this control cluster alongside the rest of your ISMS build. And if any of the terminology in this piece — RBAC, phishing-resistant MFA, need-to-know — needs a plain-language reference for a colleague newer to the standard, point them to our ISO 27001 glossary of terms.
None of this requires waiting for a full ISMS to mature before you start. If you're earlier in your certification journey and haven't yet formalized your broader access control policy, it's worth working this cluster in parallel with the organizational controls covering access control, identity management, authentication information, and access rights rather than sequencing one strictly after the other — in practice, the technical controls in this article and the policy-level controls that govern them get built, tested, and audited together, and treating them as a single workstream saves a second round of stakeholder interviews later.
Marcus Delaney's stolen laptop bag cost Halloway Fulfillment just over $3.1 million. The controls that would have prevented most of that damage — fleet-wide encryption, session timeout on cached credentials, MFA on the VPN, and a source code repository that wasn't wide open to a compromised endpoint — would have cost a fraction of that to implement in the first place. That gap, more than any audit requirement, is the actual argument for taking this control cluster seriously.