A standard that prescribes mechanisms will eventually prescribe one an unattended device cannot implement. ISO/IEC 27002:2022 is not written that way. Each control states an outcome and a purpose, and the guidance beneath it offers means rather than mandates. For a device that authenticates an engineer with no network in reach, this changes the nature of the problem: there is rarely a head-on conflict to argue about, and the difficulty moves to evidence — what an auditor can be shown, given that the machine spent the audit period disconnected.

Where ISO is more accommodating than a prescriptive standard

The clearest case is revocation. PCI DSS states it in one line — access for terminated users is revoked immediately — which is a hard thing to mean literally on a fleet that is offline. 27002 asks for the same outcome with different tolerance. Control 5.18 requires that access rights be “provisioned, reviewed, modified and removed in accordance with the organization’s topic-specific policy on and rules for access control”, and its guidance asks for

ensuring access rights are removed when someone does not need to access the information and other associated assets, in particular ensuring access rights of users who have left the organization are removed in a timely fashion

“Timely” is a risk judgement, not a deadline. A revocation list that reaches a device on a defined schedule can satisfy it, provided the interval is stated, justified and reviewed. The same control then goes further and describes short-lived credentials by name, asking the organization to consider

giving temporary access rights for a limited time period and revoking them at the expiration date, in particular for temporary personnel or temporary access required by personnel

and lists among the means of removing access the “revocation or replacement of keys, authentication information, identification cards or subscriptions”. A credential that expires on its own is not a workaround here. It is one of the mechanisms the standard had in mind.

The standard names the mechanism

Control 8.5, secure authentication, is unusually direct in its guidance:

Where strong authentication and identity verification is required, authentication methods alternative to passwords, such as digital certificates, smart cards, tokens or biometric means, should be used.

Certificates on a token are not something to justify against a password-shaped rule; they are the named alternative. And the password machinery elsewhere is conditional in the standard’s own words. Control 5.17’s requirements for a password management system open with “When passwords are used as authentication information” — where none are used, the subsection has nothing to bite on, without any argument required.

Identity, account, and the person behind both

Control 5.16 asks that the full life cycle of identities be managed, and its guidance draws the line an unattended device has to think about:

for identities assigned to persons, a specific identity is only linked to a single person to be able to hold the person accountable for actions performed with this specific identity

followed immediately by the allowance that identities assigned to multiple persons “are only permitted where they are necessary for business or operational reasons and are subject to dedicated approval and documentation”.

On a self-service device the operating-system account is usually a role — operator, service, administrator — shared by whoever holds that role. The identity is not the account. If the person is established cryptographically at sign-in and their name lands in the record of that sign-in, accountability attaches to the person while the account stays a role. The business justification and the approval remain paperwork the organization owes, exactly as the guidance says.

The evidence has to come off the device

This is where an offline fleet actually costs work. Control 8.15 asks that logs “record activities, exceptions, faults and other relevant events” and lists what each event should carry: user IDs, dates and times of relevant events including log-on and log-off, device identity and location, system activities. Among events to consider logging: successful and rejected access attempts, use of privileges, creation, modification or deletion of identities.

None of that requires connectivity to produce — but all of it has to be produced locally and survive until someone collects it. On a connected estate these records accumulate centrally as a side effect of authentication happening centrally. On a disconnected device nothing accumulates anywhere unless the device writes it down itself, and an auditor asking for the sign-in history of a specific machine over the past year is asking for something the device either kept or did not.

Control 5.18 also asks for “maintaining a central record of access rights granted to a user identifier” and “a record of changes to users’ logical and physical access rights”. Where credentials are issued centrally and enforced locally, that record is the issuance journal — the one place that does see everything, because issuing is the step that is never offline.

Where this design does not help

Control 8.5’s guidance on log-on procedures includes

terminating inactive sessions after a defined period of inactivity, especially in high risk locations such as public or external areas outside the organization’s security management

That description fits a self-service device more exactly than most things written in a standards document, and it has nothing to do with how the engineer authenticated. Idle-session termination is a property of the operating system’s session and screen-lock configuration; it has to be configured on the device and evidenced separately. A sign-in mechanism that claimed this control would be claiming someone else’s work.

The same holds for controls adjacent to access: physical security of the enclosure, integrity of the software on the machine, time synchronization for the logs to be correlatable. 8.15 notes that synchronized time sources matter because they allow correlation of logs between systems — on devices that reconcile with a central clock rarely, that is a real question to answer rather than assume.

Honest boundaries

ISO/IEC 27001 certifies an organization’s management system, not a product. No tool is “ISO 27001 certified” in a way that transfers to its buyer, and Tessera holds no such certification. What a design can do is make specific controls easier to evidence — and, for the ones above, make the evidence available from a machine that spent the year offline.

Sources