How credential-based login works
The model in full: what an engineer's credential records, how authority narrows from the fleet owner to the contractor and on down to a permit for a single shift, the order in which a device verifies a login without reaching the network — and what this scheme does not do.
In brief
The right to log in to a device is described entirely inside the engineer's digital credential, and the device verifies that credential on its own — offline, without reaching a server.
Terms
| Term | Meaning |
|---|---|
| Device | A unit of the fleet: an ATM, a payment terminal, a workstation |
| Credential | The engineer's digital document establishing the right to log in. It records the scopes and the validity period, all signed together by the issuer |
| Role | A set of rights on the device. Each role corresponds to a role account the engineer logs in under: the role in the credential points straight at it |
| Issuer | The party that signs credentials: the fleet owner, or a contractor the owner has authorized |
| Root certificate | The fleet owner's certificate placed on the devices. A device trusts only credentials whose signature chain converges on it |
| Scopes | The limits a device verifies: which devices the access covers, which roles may be granted, up to what privilege ceiling and for how long. Every next link in the chain can only narrow them |
| Shift permit | The last link in the chain: a credential issued to an engineer for one device, one role and a few hours |
| Medium | The USB stick or token on which the engineer carries the credential to the device |
How it is put together
What changes compared with common practice
| Question | The usual way | In the scheme described |
|---|---|---|
| What the engineer logs in with | An account created on the device, with a password | A medium carrying a credential; the account on the device is a role account, shared by everyone allowed that role |
| Where "who is allowed" lives | On the device and in a directory; the two must be kept in sync | In the credential itself, under the issuer's signature |
| Whether the device needs a network | Yes — without one the directory is unreachable and the login cannot be checked | No — verification is entirely local |
| How to constrain a contractor | Organizationally: by contract, and by trusting its administrator | Technically: the scopes are written into its credential and verified by the device |
| How to withdraw access | Disable the account — which requires reaching the device | Wait out the validity period (hours), or distribute a revocation list |
| How an engineer first gets access | Travel to an issuing point to collect a medium or an account | Remotely: the medium stays with the engineer, and only files travel over the channels |
| What an incident review can see | That someone logged in under an account | An entry in the issuance record: to whom, when, and with which scopes the credential was issued |
The problem
Fleet devices stand where there is neither a permanent trusted network nor an administrator on site. They are serviced by people who, more often than not, do not report to the fleet owner at all.
Three circumstances that decide everything
The device cannot ask a server. The channel to the device is either absent entirely, or not considered trusted, or unavailable at precisely the moment an engineer has arrived to fix a fault. A scheme where a central directory confirms the login stops working right then: the engineer is standing at the device and cannot get in. The workaround — a local account with a password "in case the link is down" — becomes the main path in practice, and reduces control to nothing.
A contractor does the work. The fleet owner does not know by name which engineers will turn up for a shift, and does not control their hiring or dismissal. Entering each of them into its own directory means running somebody else's HR records with an unavoidable lag: an employee dismissed by the contractor stays active at the fleet owner.
8.2.5, 12.8.4, 12.8.5
Access for terminated users must be revoked immediately (8.2.5), and the entity has to monitor its third-party service providers and record which requirements each of them manages (12.8.4, 12.8.5). The hard part is the second half: the people being terminated work for the contractor, not for you. The scheme supplies the mechanics — on notice, one engineer's credential is revoked, with no trip around the fleet and no password change on the devices — and the issuance record shows exactly which permits that contractor had issued.
Access needs to be narrow and short. An engineer on a shift needs one device for a few hours and one set of operations. What actually gets issued is open-ended, covers the whole fleet and carries administrative rights — because drawing distinctions is harder than handing over everything at once.
What follows from this
What is needed is a scheme where the decision about who may do what is made in advance and travels with the engineer, while the device only verifies its authenticity and its scopes. Then the absence of a link stops being a problem, HR records stay with the contractor, and the extent and duration of access are set at the moment of issuance.
The principle: the right to log in is written into the credential
A credential does not grant access without limits. It grants access with precisely stated scopes: to which devices, under which role, and until when. The scopes are signed together with the credential itself, so they cannot be changed after issuance.
How the device knows whom to trust
At installation the device receives the fleet owner's root certificate — and nothing else personal. It stores no list of engineers, no passwords, no details about contractors. All it can do is verify that the credential presented was issued along a chain leading to that certificate, and that the scopes of every link in the chain are respected.
From this follows the main practical property: adding a new engineer requires nothing to be done to the devices. A credential is issued, and the fleet accepts it immediately — because the fleet trusts a signature, not a list of people.
Why this works without a network
Everything needed to decide on a login sits in two places: the root certificate on the device, and everything else on the medium the engineer brought along. Verifying a signature is a local computation. The one place where the scheme could in principle reach the network is the revocation check, and its source is chosen explicitly during configuration. For environments without connectivity a local revocation list is selected, and then no network calls arise at all.
Control over access stays entirely with the fleet owner, while the owner takes no part in day-to-day operations. The scopes are set when authority is granted to the contractor; from then on the contractor works inside them unaided, and cannot step outside them by any technical means.
The delegation model
Authority is passed along a chain, and at every step it can only narrow. That property is verified by the device — it does not rest on the good faith of the links.
Fleet owner
A bank, an industrial company, a critical-infrastructure operator. The root of trust — only the owner decides who may do what.
rights: entire fleetOrganization certificate
- devices: region "North" only
- roles: "maintenance" only
- issued credentials: ≤ 30 days
rights narrowed to the contractor's scope
Service organization
The contractor. Issues credentials to its own engineers — but only inside the scopes it was given.
rights: region · 1 roleEngineer's shift certificate
- device: device no. 0042 only
- role: "maintenance"
- valid for: 8 hours
rights narrowed to a single shift
Engineer
Arrives on site with a certificate on a USB stick or token. Needs no network.
rights: 1 device · 8 hLogin to the device
- the device verifies the whole certificate chain itself, offline
- the session opens at exactly the requested level — never more
least privilege at login
Device
Any device running Linux / Astra Linux. Verifies signatures, scopes, expiry and revocation — without a single network call.
offline validationWhy a contractor cannot step outside its scopes
A contractor's limits are written into its own authority and signed by the fleet owner. At login the device checks every link in the chain at once: the resulting right is the intersection of each link's scopes. If the contractor issues its engineer a permit wider than the one it holds — for someone else's region, for a forbidden role, for longer than allotted — the device refuses the login, because it compares what is requested not only against the last permit but against the scopes above it.
Security does not depend on the contractor's good faith, nor on how carefully its tools are configured. A mistake or an abuse on its side leads to a refused login, not to widened access.
Which limits can be set
| Limit | What it sets | Example |
|---|---|---|
| Device group | Which subset of the fleet the authority covers. Devices are tagged with attributes (region, site, model); the authority requires a match on those attributes | region = north only |
| Role list | Which roles the contractor may grant its engineers. Roles outside the list are unavailable even if the contractor issues them | maintenance, cash replenishment — but not administration |
| Privilege ceiling | The upper bound on privileges inside the protection mechanisms of the device's operating system | level 5 at most |
| Duration ceiling | The maximum validity of a permit the contractor issues to an engineer | 8 hours per permit at most |
The chain has no depth limit: a contractor may delegate authority to a subcontractor, which may delegate to its own unit, and so on. The narrowing rule applies at every step, so a longer chain does not weaken control.
How the scheme maps onto work orders
The last link in the chain — the shift permit — matches, field for field, the work order that operations already raise in advance. The order answers exactly the questions that have to be written into the credential.
| Work order field | What it becomes in the permit |
|---|---|
| The device the work is performed on | the binding to that device |
| The nature of the work | the role — and with it the extent of rights on the device |
| The execution window | the permit's validity period |
| The performer and their organization | whom it was issued to, and along which chain of authority |
Issuing a permit becomes a continuation of approving the order rather than a separate procedure: the order is approved, and the engineer holds a permit for exactly that device, that role and that window. The work ends, the permit expires on its own, and there is nothing to revoke by hand.
Access without a work order is technically impossible. No order, no permit, and the device refuses the login — so enforcing the work procedure moves out of reporting and into an actual prohibition.
The issuance record reconciles one-to-one with the register of orders. Every login on a device corresponds to a permit issued, and every permit to an approved order. A discrepancy shows up immediately, without polling the devices.
Issuing permits stays with the contractor all the while — inside the scopes the fleet owner granted. The owner need take no part in arranging each shift: it set the boundaries, and the device is what checks they are respected.
What a credential records
An engineer's credential is a standard X.509 digital certificate with added fields describing the access scopes. The format is standard, so credentials can be issued and stored with existing tooling.
| Field | What it means | Where it appears |
|---|---|---|
| Device binding | The list of devices the credential is valid on. The device compares its own identifier against that list. An "any device" variant is possible — for roving administrators | the engineer's credential |
| Permitted roles | The roles the engineer may activate at login; each corresponds to a role account on the device. Roles outside the list are unavailable | the engineer's credential |
| Privilege ceiling | The upper bound on session privileges inside the protection mechanisms of the device's operating system | the engineer's credential |
| Validity period | Start and end. Once it expires the credential stops being accepted, with no action required from the fleet owner | every link |
| Delegation scopes | The envelope of authority: device group, role list, privilege ceiling and duration ceiling for everything below. Checked across all links of the chain at once | the contractor's authority and that of any intermediate link |
| Profile version | Protection against accepting credentials issued under outdated rules; lets the rules be updated across the fleet in a controlled way | the engineer's credential |
In processes where the engineer composes the issuance request, they may state the roles and bindings they want — but those wishes are not applied. The issuer sees what was requested and sets the final scopes itself. Choosing an issuance process is a decision about who holds the key, not about who controls the rights.
8.3.9
Where a password is the only authentication factor, it has to change at least every 90 days. On an offline fleet that means a mechanism delivering a new password to every device four times a year — and proving the delivery landed. Here rotation is replaced by the validity period written into the credential itself and checked by the device without reaching a server, so it holds on devices that have no connection at all.
Role accounts on the devices
The role in the credential points at the role account the engineer logs in under. The role accounts themselves, their groups and their command privileges have to be uniform across the fleet; bringing a fleet to that single description is a separate task, solved outside the login path and unrelated to issuing credentials.
8.2.2
Shared accounts are the obvious objection to a role account, and PCI DSS answers it directly rather than by exception. Requirement 8.2.2 permits group, shared or generic accounts on an exception basis, subject to conditions: use is limited to the time needed, the business justification is documented, management approves it, the individual user's identity is confirmed before access to the account is granted, and every action taken is attributable to an individual user.
The last two conditions are what this scheme does by construction. Identity is confirmed by a named engineer's credential before the session opens — not by knowledge of a shared password. The device log records which credential opened the session, so actions taken inside it attribute to that engineer.
The remaining conditions — the justification, the approval, the time limit — are the organization's to document, though the time limit is already enforced by the permit's validity period rather than by procedure. An assessor will ask about shared accounts; this is the answer, and it rests on the requirement's own wording rather than on a compensating control.
Logging in on the device
The engineer connects the medium and enters its secret. From there the device runs its checks in a fixed order. Any check that does not pass means refusal.
8.4.2, 10.2.1.1, 10.2.2
Multi-factor authentication is required for all access into the cardholder data environment, not only for administrators (8.4.2). An engineer at the service panel is access too. Here both factors are real and both are checked on the device: possession is the medium, knowledge is its secret.
Audit logs must capture individual user access and record who did it, what kind of event it was, and when (10.2.1.1, 10.2.2). The device writes that entry itself, offline, naming the credential the session was opened with.
The scheme is built so that doubt resolves to refusal. A missing mandatory field, content that failed to parse, an unavailable revocation list, an unreadable medium, a signature that did not converge — each of these produces a login that did not happen, never a fallback to some general-purpose access. There is no mode in which a failed check is waived.
What the engineer sees on refusal
The engineer is given a general reason — enough to know what to do next (wrong medium, expired credential, wrong secret) — without revealing how the fleet is configured. The detailed reason goes into the device log, where operations can read it.
When no medium is issued at all
Where the logistics of media make no sense — one-off visits, a wide circle of contractors — the engineer's phone can serve as the second factor: a code from the device screen is confirmed in an external loop, and the engineer types the reply code back in. The device still makes the decision itself. That is a separate delivery option and is not examined further here.
Issuance processes
A credential can be issued in five ways. They differ not in convenience but in who ends up knowing the private key and what travels over the channels. That decision determines whether the credential can support the claim that the engineer it was issued to is the one who used it.
The two attributes that define a process
Where the private key is born is the main attribute. It sets how many secrets pass between people, and what the proof of authorship rests on.
The medium is the second attribute. It determines only who can physically reach the credential. A medium does not by itself protect the key from copying: a private key comes off a passive token exactly as it comes off a USB stick.
In none of the five processes does a medium have to be prepared in advance at an issuing centre and physically delivered there. The USB stick or token stays with the engineer throughout: only files travel over the channels, and the engineer writes the credential onto the medium personally, at their own workplace.
In the processes built on an issuance request — P2, P4 and P5 — the key itself is also born on the engineer's side: in software at the workplace (P2, P4) or inside the token in their hands (P5). The issuer receives only a request and returns only a credential; neither the key nor the medium ever reaches it.
Preparation and issuance therefore happen entirely remotely, and the logistics of media drop out of the scheme: a remote engineer, or a contractor's engineer in another region, gets access where they are — no travel, no couriered tokens.
What actually differs
| Key at the issuer (P1, P3) |
Key at the engineer (P2, P4) |
Key on the token (P5) |
|
|---|---|---|---|
| A secret can leak through the channel | possible | impossible | impossible |
| What travels over the channels | a container holding the private key, and its password | a request and a credential | a request and a credential |
| Who knows the private key | the issuer and the engineer | the engineer only | nobody — the key never leaves the token |
| Whether the credential points to one specific person | no: two parties knew the key; only the issuance record ties it to a person | yes: only the engineer held the key | yes: only their token could have signed |
| If the medium is lost | depends on the medium, see section 8 | depends on the medium, see section 8 | nothing to copy; guessing the secret runs into the token's retry counter |
| If the issuer is compromised | every key it issued leaks | the right to issue new ones leaks | the right to issue new ones leaks |
| What the engineer needs | to receive two artefacts | tooling at the workplace | tooling and an active token |
What travels over the channels
| Artefact | Holds a secret | Channel requirement |
|---|---|---|
| Issuance request | no | integrity |
| Issued credential | no | integrity |
| Chain of trust, revocation list | no | integrity |
| Container holding the private key | yes | confidentiality and integrity |
| Container password, token access secret | yes | a channel other than the container's |
In P2, P4 and P5 not a single secret travels over the channels — intercepting the correspondence yields nothing. In P1 and P3 there are two secrets, and both leave the issuer. The steps below show how that looks.
8.3.2
Strong cryptography must render all authentication factors unreadable during transmission and storage. P2, P4 and P5 satisfy this by construction: there are no secrets in the channels at all. P1 and P3 transmit the container and its password, so they require separated channels and organizational measures on top — which is the main difference between the processes from an assessor's point of view.
Process P1 / P3 — the issuer generates the key
The container and its password are delivered over different channels. A message carrying both reduces the container's protection to nothing: whoever read that message now holds a working credential.
Process P2 / P4 — the engineer generates the key
Process P5 — the key is born inside the token
How to choose
P1 and P3 suit a large, changing pool of engineers where nobody can install tooling on their workplaces. The price: two secrets leave the issuer, and from that moment the private key is known to both sides. The credential alone cannot say who used it; only the issuance record ties it to a person.
P2 and P4 suit the case where tooling can be installed on the engineer's workplace but active tokens are unavailable. The key never leaves the engineer, and nothing secret travels over the channels.
P5 is the only process in which the private key never leaves the device at all. It requires active tokens and tooling at the engineer's side, and it gives the strongest tie between a credential and a person.
8.4.1, 8.4.2
MFA is required for administrative non-console access into the cardholder data environment (8.4.1) and for all access into it (8.4.2). A hardware possession factor comes only with active tokens — process P5. In P1–P4 the possession factor is the medium and the knowledge factor is the container password or the token access secret. Whether that pair counts as two independent factors is a question for your assessor; this page does not answer it.
The choice is not made once for the whole fleet. Active tokens (P5) make sense for the fleet owner's own engineers, while contractors with a changing roster can work under P1 or P3. The delegation scopes stay common to everyone regardless.
Enrol once, issue many times
In the processes built on an issuance request — P2, P4 and P5 — the engineer composes that request once. From then on the issuer can produce any number of credentials against it: one per work order, each with its own scopes and its own validity period.
That is by design: an issuance request is the engineer's enrolment, not an application for one particular credential. For P5 it could hardly be otherwise — the key is generated inside the token once and lives there permanently. Issuing a shift permit therefore asks nothing of the engineer: they enrolled once, and after that a fresh credential is written for each work order.
The opposite is equally unconstrained: the engineer may compose a new request before every issuance, in which case the key is new each time. How often enrolment is renewed is the fleet owner's decision; renewal means a new key pair — inside the token in P5, at the workplace in P2 and P4.
On each issuance the engineer writes the credential onto the medium: reassembling the container in P2 and P4, writing an object into the token in P5. It is a local operation at their workplace — neither the key nor any shipping of media is involved.
What this means for operations
| Consequence | What to plan for |
|---|---|
| One key across many credentials | Until enrolment is renewed the engineer keeps using the same key. In P2 and P4 that key lives at their workplace, and losing it devalues not one credential but every subsequent issuance under that enrolment. In P5 the key cannot be copied — so the less often enrolment is renewed, the stronger the case for active tokens |
| Identity is confirmed at enrolment | Every later issuance trusts the stored request. The request is not secret, but substituting it would mean issuing credentials for someone else's key under the engineer's name — so the enrolment store needs integrity control, and the in-person identity check belongs at the enrolment stage |
There the issuer generates the key every time, so enrolment does not exist as a separate step: each issuance stands alone and comes with two secrets in transit.
Checking the credential before departure
In every process the engineer verifies the credential at their workplace: that it matches the key, that the chain converges, that it has not expired, that the role is present, that the mandatory fields are there. Without this step an unusable credential surfaces at the login screen — at a device where nothing can fix it. The device binding cannot be checked at the workplace: the engineer is not sitting at the device the credential was issued for.
Media
The medium determines who can reach the contents if it is lost or stolen, and whether the private key can be copied off it.
| Medium | What it holds | Key copyable | Secrets |
|---|---|---|---|
| USB stick | container as a file on a partition | yes | container password |
| Passive token | container as a private data object | yes | token access secret and container password |
| Combined token | either role, depending on configuration | yes | as for the chosen role |
| Active token | key and credential as device objects | no | token access secret |
What a finder can do
| Medium | What the finder can do |
|---|---|
| USB stick | Copy the container and brute-force the password on their own equipment, with no limit on attempts. Protection comes down to the strength of that password |
| Passive token | Nothing until the access secret is passed: the container sits as a private object, and attempts are capped by a hardware counter — the token locks itself |
| Active token | Nothing: the private key cannot be extracted at all, there is nothing to copy, and attempts are capped by the counter |
It follows that a passive token is stricter than a USB stick, even though the key copies off it just the same: brute-forcing the password on your own equipment is no longer available, because the container has to be reached first.
In P1–P4 the private key can be copied off the medium, so a copy taken together with the password works exactly like the original. That is how any scheme with a copyable key behaves — it is not an implementation defect. The one way to remove the property is active tokens (P5).
Token support rests on a standard interface and the vendor's own library, so the fleet is not tied to one model: widely available PKCS#11 tokens work, and the mix of models can change over time without altering either the issuance scheme or the device configuration.
Revocation and a lost medium
The scheme has two independent ways of ending access. The main one works with no connection to the device at all.
Why a short validity period is the main instrument
A revocation list has to be delivered to the device, and delivery is precisely what is unreliable in this kind of environment. The load therefore shifts onto the validity period: the shorter the permit, the smaller the window in which revocation is relevant at all. A permit for a single shift turns the revocation list into an instrument for exceptional cases rather than a daily one.
When the revocation check is configured against a local list, the device refuses the login if the list is missing and — where a maximum age is set — if it is stale. Keeping the list updated across the fleet is therefore a mandatory part of operations, not an optional extra. The update interval and the acceptable age are chosen according to what delivery can actually achieve.
What to do when a medium is lost
- The engineer reports the loss; the issuer adds the credential to the revocation list.
- The updated list is distributed across the fleet in the usual way.
- If the lost permit was issued for a shift, no separate fleet-wide action may be needed — it will expire before the list finishes propagating.
- The engineer is issued a new credential in the normal way.
- The loss and the revocation are recorded in the issuance record.
The issuance record
Every issuance is written into the issuance record whatever process was used. The entries are linked by a hash chain: removing or altering an entry after the fact without breaking the chain is not possible.
What the record shows
- to whom a credential was issued, and when;
- with which scopes — devices, role, privilege level, validity;
- who the issuer was, and along which chain of authority it acted;
- which process was used — in particular, whether the issuer generated the key;
- revocations.
All of this is available without touching the media and without polling the devices — which matters in an environment where devices are unreachable over the network.
8.2.4
Adding, deleting and modifying user IDs and authentication factors has to be authorized with the appropriate approval and implemented with only the privileges named in that approval. The issuance record is the direct evidence: it shows who issued what, to whom, with which scopes and along which chain of authority — and the hash chain means removing or substituting an entry after the fact is detectable. The hash chain protects the issuance record specifically; the device's own event log is kept by the operating system's standard facilities.
In P1 and P3 the record is the only thing tying a credential to a person: two parties knew the private key, and the credential itself points at no individual. In P2, P4 and P5 the credential itself provides the tie, and the record remains an accounting instrument. The stricter the demands on proving authorship of actions, the stronger the case for P5.
The device log
Separately from the issuance record, each device keeps its own log of login events: successful logins naming the credential presented, refusals with their reason, media removals and the actions they triggered. The device log is forwarded to the fleet owner's event collection system by the operating system's standard facilities whenever a connection is available.
What the fleet side needs
The scheme describes the mechanics of verification; it does not decide for the fleet owner who may do what. Those are access policy decisions: the owner makes them in advance rather than at each login, and from then on the devices carry them out unaided.
What the fleet owner decides
| Decision | What it covers |
|---|---|
| The root certificate and its key | Where the key that signs contractors' authority is held and how it is protected. In practice: a hardware medium or a cryptographic module, with access under a documented procedure |
| The role model | Which roles exist on the devices, which rights they carry, and who may grant them |
| Fleet tagging | The device attributes (region, site, model) the delegation groups are cut along |
| Contractor scopes | For each contractor: device group, role list, privilege ceiling, duration ceiling |
| Issuance process | One or several of P1–P5, by category of engineer (see section 7) |
| Engineer enrolment | Where issuance requests are stored, who may accept them, and how often enrolment is renewed — from once for an engineer's whole tenure to a fresh one before every issuance (see section 7) |
| Link to the work order system | Whether an approved order counts as grounds for issuing a permit, and how far issuance is tied to it procedurally or automatically (see section 4) |
| Revocation list updates | By which channel and how often lists reach the devices; the acceptable age of a list |
| Response to media removal | Lock the screen, end the session, or shut the device down |
What the devices need
- The root certificate placed on every device at installation or as part of the image.
- Uniform role accounts across the whole fleet.
- A delivery channel for revocation lists — any channel, down to carrying them on a medium during a visit.
- A port for the medium that the engineer can reach, and a procedure for handling it.
PCI DSS requirements the scheme supports
A summary of the notes placed through the text. Below are the requirements whose implementation the scheme supports, and what evidence an assessor gets for each.
Assessment applies to an entity, not to a piece of software. The scheme is not "PCI DSS compliant" and does not deliver compliance on its own: it supports the implementation of specific requirements and produces evidence for them — credentials, configurations and logs. Most of the requirements listed have an organizational part that no technical control can close.
Requirement 8 — identify users and authenticate access
| Req. | What it asks | How the scheme supports it |
|---|---|---|
| 8.2.2 | Group, shared or generic accounts only on an exception basis, with identity confirmed before access and every action attributable to an individual | The role account is shared, but identity is confirmed by a named engineer's credential before the session opens, and the device log records which credential opened it. The justification, the approval and the time limit stay with the entity — though the time limit is already enforced by the permit's validity |
| 8.2.4 | Additions, deletions and modifications of identifiers and authentication factors authorized with approval, implemented with only the approved privileges | The issuance record with its hash chain: who issued what, to whom, with which scopes and along which chain of authority. Removing or substituting an entry after the fact is detectable |
| 8.2.5 | Access for terminated users revoked immediately | On notice the engineer's credential is revoked — no trip around the fleet, no password change on the devices. In parallel a short validity means an unreported departure closes its own window within hours |
| 8.3.1 | All user access authenticated by at least one authentication factor | Authentication happens on the device against the credential; there is no mode in which a failed check is waived |
| 8.3.2 | Strong cryptography renders authentication factors unreadable in transmission and storage | In P2, P4 and P5 no secret travels over the channels at all. P1 and P3 transmit a container and its password, so they require separated channels and organizational measures on top |
| 8.3.9 | Where a password is the only factor: change it every 90 days, or analyse access dynamically | There is no password to rotate. Rotation is replaced by the credential's validity period, which is checked by the device locally and therefore expires even on a device with no connection |
| 8.4.1, 8.4.2 | MFA for administrative non-console access into the CDE, and for all access into the CDE | A hardware possession factor comes with active tokens (P5). In P1–P4 possession is the medium and knowledge is the container password or token secret; whether that pair counts as two independent factors is for the assessor to decide |
Requirements 10 and 12 — logging, and third-party providers
| Req. | What it asks | How the scheme supports it |
|---|---|---|
| 10.2.1.1 10.2.2 |
Audit logs capture individual user access and record who, what kind of event, and when | The device writes the entry itself, offline, naming the credential the session was opened with and the role activated; refusals are logged with their reason. The issuance record ties each login back to a specific issuance |
| 12.8.4 12.8.5 |
Monitor third-party providers' compliance, and record which requirements each of them manages | The scopes granted to a contractor are that record, in machine-checkable form: which devices, which roles, which ceilings. The issuance record shows what the contractor actually issued inside them, without asking the contractor |
What to show an assessor
The device configuration serves as evidence in its own right: which media and modes are permitted, and which checks run at login.
Boundaries of the solution
What follows is a list of what the scheme does not do. It is here deliberately, so that expectations going into a deployment are the right ones.
| Not solved by the scheme | Why |
|---|---|
| Protection against copying the medium in P1–P4 | In these processes the private key can be copied off the medium, and a copy together with the password works exactly like the original. Only moving to active tokens (P5) removes this |
| Proof of authorship in P1 and P3 | The private key is known to both the issuer and the engineer. The tie to a person comes from the issuance record, not from the credential itself |
| Protection against compromise of the device's operating system | The scheme is responsible for the login decision. Anyone who has gained full control of the device is outside its perimeter |
| Immediate revocation on disconnected devices | Revocation takes effect as the list is delivered. The primary limiting mechanism is the permit's short validity period |
| Bringing the fleet's role accounts to a single form | An adjacent task, solved separately and outside the login path; the scheme assumes the role accounts on the devices are already uniform |
| Managing token access secrets | Issuing, changing and unblocking token secrets is the responsibility of whoever owns the media |
The admission decision is made by the fleet owner in advance and explicitly; the contractor works inside the scopes it was granted and cannot widen them; the device verifies the right to log in itself, without a network; the access granted is narrow in extent and finite in time; and every issuance is accounted for in a tamper-evident record.