Standards differ in how much they tell you to do. ISO/IEC 27002 states outcomes and leaves the means open. PCI DSS prescribes controls but publishes an objective for each. A hardening baseline sits at the far end: it names the file, the setting and the value. The RHEL 9 Security Technical Implementation Guide runs to 446 rules, each with a command that either returns the expected string or produces a finding.

That precision is the point. It is also where an unattended device runs into trouble, and the trouble is more interesting than “the baseline is too strict”.

The baseline asks for exactly this design

Two rules are worth reading together. The first requires certificate-based smart card authentication — checked, in the STIG’s usual style, by grepping a configuration key:

To verify that RHEL 9 has smart cards enabled in System Security Services Daemon (SSSD), run the following command: $ sudo grep -ir pam_cert_auth /etc/sssd/sssd.conf /etc/sssd/conf.d/ … If “pam_cert_auth” is not set to “True”, the line is commented out, or the line is missing, this is a finding.

A hardening baseline for a general-purpose operating system requires login by certificate on a token. Nothing to argue with; it is the mechanism.

The second rule, immediately after, requires certificate status checking — and names the protocol:

Verify the operating system implements Online Certificate Status Protocol (OCSP) and is using the proper digest value on the system with the following command: $ sudo grep -sir certificate_verification /etc/sssd/sssd.conf /etc/sssd/conf.d/

OCSP is a request to a responder over the network, made at the moment of authentication. On a machine with no connectivity at sign-in there is no responder to ask. The rule cannot be satisfied as written, not because the design is weak but because the prescribed mechanism needs a network that is not there.

A related rule requires validating certificates “by constructing a certification path (which includes status information) to an accepted trust anchor”. Path construction is local; the status information is the part that reaches outward.

The offline answer is a revocation list distributed on a schedule and a short validity period, which is what PCI DSS’s revocation requirement and ISO/IEC 27002 both accommodate. It is not what this rule says.

The escape hatch nobody quotes

Each of those identity rules carries the same note, in the check text rather than in the requirement:

If the system administrator (SA) demonstrates the use of an approved alternate multifactor authentication method, this requirement is Not Applicable.

This is the baseline’s equivalent of PCI’s customized approach and ISO’s outcome framing, and it is easy to miss because it appears as a note to the assessor rather than as a right granted to the implementer. The word doing the work is “approved” — approved by the authorizing official for that system, not by DISA and not by a vendor. So the offline argument is available, but it is an argument to be made and signed off, not a checkbox.

Three standards, three different lockout rules

The same disagreement shows up in a smaller place. PCI DSS asks for lockout after not more than 10 invalid attempts, for at least 30 minutes or until identity is confirmed. This baseline is stricter and more absolute:

Verify RHEL 9 is configured to lock an account until released by an administrator after three unsuccessful logon attempts with the command: $ sudo grep -w unlock_time /etc/security/faillock.conf — unlock_time = 0

Three attempts, and no automatic release at all. A hardware token’s own PIN counter behaves closer to this than to PCI’s version — it blocks and stays blocked until someone unblocks it. Which is a reminder that “brute-force protection” is not one requirement with one number: three documents give three, and the one that applies is whichever the assessor holds.

What the baseline does not cover

Look at what all 446 rules have in common: they describe the state of one machine. Nothing in a hardening baseline says who should be given a credential, on what authority, for how long it stays valid, how it is renewed, how it is revoked across ten thousand machines, or how you prove afterwards which person opened which device.

That is not a gap in the document — it is a different problem. A baseline answers “is this machine configured correctly”. Identity lifecycle answers “should this person be able to open it today”. A fleet can be perfectly compliant with every rule here while sharing one service password across every device in the country, because no rule in a machine-scoped baseline can see the fleet.

One rule sits exactly on the boundary and is worth noting for honesty. The baseline requires a session lock when the smart card is removed — and its check begins by saying the requirement is Not Applicable if no graphical interface is installed, because the setting it inspects belongs to the desktop environment. Even where a baseline reaches for the behaviour, it assigns it to the operating system, not to whatever performed the authentication. That has been the same answer in every standard we have read on these devices.

Honest boundaries

A STIG is written for US Department of Defense systems and its specifics — DOD PKI, CAC drivers, approved trust anchors — belong to that context. Nobody outside it is obliged to follow the file paths. What travels is the shape of the problem: a baseline that prescribes mechanisms will prescribe ones that assume connectivity, an offline device will fail those rules as written, and the escape hatch requires someone with authority to accept an alternative.

If you run devices that authenticate people without a network, the useful exercise is to read your baseline for exactly two things: which rules name a protocol rather than an outcome, and where the document says “not applicable” and who is allowed to say it.

Sources