SIAS-IAM-01 Unique identities and account lifecycle
- Mandatory
- Yes
- Severity
- High
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
Every action on an in-scope system can be traced to one accountable person, and an account exists only while a current, authorized need for it exists.
Testable requirement
- The applicant must:
- 1.give each person who accesses in-scope systems a unique user identity that is not shared with, or later reassigned to, another person;
- 2.not use shared or generic accounts for interactive access, except where the platform requires one (for example a cloud root account or a device's built-in administrator). Each such account must be listed with a named owner, its credential held in a password vault or privileged access tool that records each checkout by an individual, and its use logged;
- 3.create accounts and grant initial access only after a recorded request that the person's manager or the system owner has authorized;
- 4.use a central identity provider or directory for every in-scope system that supports one, and keep a list of in-scope systems that still use local accounts, with the person responsible for their lifecycle;
- 5.disable the access of separated personnel within these limits: remote and privileged access by the end of the person's last working day, and immediately on notice of an involuntary separation; all other access within 1 business day of separation;
- 6.disable accounts with no successful sign-in for 90 days, unless a documented exception names an owner and a reason.
Applicability and scope
All scopes. Covers workforce members, contractors and third-party personnel with accounts on in-scope systems, including local accounts on in-scope servers, databases, network devices and SaaS applications. Non-human accounts are assessed under SIAS-IAM-06. Not part of any SecurityInspect Verified profile.
Pass criteria
- 1.Every active account in E2 and E3 maps to one current person, or to a listed shared account with a named owner.
- 2.No account of a separated person is active at the time of testing.
- 3.For every sampled leaver, remote and privileged access was disabled within the limit in requirement 5, and all other access within 1 business day.
- 4.Every sampled joiner had a request authorized no later than the access grant.
- 5.Every shared account is listed, owned and vaulted, with an individual checkout record for each use in the look-back period.
- 6.No account has gone more than 90 days without a successful sign-in unless a documented exception covers it.
- 7.No identity was reassigned to a different person.
Severity
High. A sign-in by a separated person's account after separation that cannot be matched to an authorized, documented activity is treated as evidence of possible compromise and escalated to Critical under the global escalation rules.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(3)(ii)(C), §164.308(a)(4)(ii)(C), §164.312(a)(2)(i)
- PCI DSS v4.0.1
- 8.2
- Trust Services Criteria
- CC6.2
- ISO/IEC 27001:2022
- A.5.16, A.5.18
- Theme (SecurityInspect wording)
- unique user IDs and account lifecycle
SIAS-IAM-02 Multi-factor authentication for remote, administrative and privileged access
- Mandatory
- Yes
- Severity
- Critical
- Applies
- All scopes
- SecurityInspect Verified profiles
- VP-APP, VP-CLD
Control objective
A stolen or guessed password alone never grants remote access to in-scope systems, or administrative or privileged access to them from anywhere.
Testable requirement
- The applicant must:
- 1.enforce MFA on every remote access path to in-scope systems, for workforce members, contractors and third-party personnel;
- 2.enforce MFA on every administrative and privileged access path to in-scope systems, whether remote or from an internal network, including command-line and API sessions that carry administrative rights where the platform supports MFA for them;
- 3.enforce MFA through technical configuration that users cannot switch off. Offering or enrolling MFA without enforcing it does not count;
- 4.disable or block, for the accounts above, any legacy or alternate authentication path that does not enforce MFA (for example basic authentication to mail or directory protocols, or application passwords that bypass MFA);
- 5.use factor types that meet these minimums: phishing-resistant factors (for example FIDO2/WebAuthn security keys or platform authenticators, or smart-card or certificate-based authentication) for top-level administrative roles in the identity provider and for cloud organization or root accounts; no SMS, voice or email one-time codes for any privileged access; push approvals only with number matching or another protection against repeated prompts;
- 6.verify a person's identity by a documented method before resetting or re-enrolling their MFA factor, and log each reset;
- 7.protect emergency ("break-glass") accounts with MFA factors held in controlled storage, alert on every use, and review each use.
Applicability and scope
All scopes. Covers every remote and every privileged access path listed in the applicant's access-path register or discovered during testing. End-user (customer) authentication inside in-scope applications is assessed under SIAS-APP-03; administrative functions of those applications are in scope here. Long-lived programmatic credentials that cannot use MFA are governed by SIAS-IAM-06. SecurityInspect Verified profiles: VP-APP (administrative access to the named application, its hosting and its deployment pipeline) and VP-CLD (all human access to the named cloud tenants or accounts).
Pass criteria
- 1.A3 and M2 found no remote or privileged access path that grants access with one factor.
- 2.No privileged or remote-access user falls within an MFA exclusion, other than break-glass accounts that meet criterion 6.
- 3.Sign-in records for the most recent 30 days show no single-factor sign-in by a privileged or remote-access user, other than documented break-glass uses.
- 4.Legacy protocols that bypass MFA are disabled for in-scope users, with no use in the most recent 30 days.
- 5.Every privileged user's registered factors meet requirement 5.
- 6.Break-glass accounts keep their MFA factors in controlled storage, every use raises an alert, and every use in the look-back period was reviewed.
- 7.Every sampled MFA reset was preceded by the documented identity verification.
- 8.Cloud root or organization accounts have MFA and no long-lived access keys.
Severity
Critical. Lowering a finding to High is possible only for a partial failure (for example one non-privileged remote path without MFA where network restrictions limit exposure), with written rationale, quality-reviewer concurrence and approval by the second independent reviewer. A gap on identity provider administration or on cloud organization or root accounts is never lowered.
Informative framework mappings
- HIPAA Security Rule
- §164.312(d)
- PCI DSS v4.0.1
- 8.4, 8.5
- Trust Services Criteria
- CC6.1, CC6.6
- ISO/IEC 27001:2022
- A.8.5
- Theme (SecurityInspect wording)
- multi-factor authentication for sensitive access
SIAS-IAM-03 Least privilege and privileged access management
- Mandatory
- Yes
- Severity
- High
- Applies
- All scopes
- SecurityInspect Verified profiles
- VP-CLD
Control objective
People and roles hold only the access their duties need, and administrative power is limited, kept apart from everyday use and traceable to a person.
Testable requirement
- The applicant must:
- 1.define access to in-scope systems by role or group, denying by default anything not granted;
- 2.keep a register of privileged roles and their holders, with a documented justification for each holder;
- 3.perform privileged tasks with a separate administrative identity, or through just-in-time elevation that expires automatically, and never from the account used for email and web browsing;
- 4.limit standing holders of top-level administrative roles in the identity provider and in each cloud organization to a number the applicant has justified in writing, and to no more than 5 per platform unless the quality reviewer accepts the applicant's written justification for more (for the highest tenant-wide role in a cloud tenant, the limit in SIAS-CLD-02 requirement (e) applies instead and is scored there; §2.11);
- 5.not use cloud root or organization-owner accounts for routine operations;
- 6.remove privileged rights that have not been used for 90 days unless the register records a justification;
- 7.log each use of privileged access to the individual (see SIAS-LOG-01). The applicant should grant permissions to groups or roles rather than directly to individuals wherever the platform supports it.
Applicability and scope
All scopes. Covers human privileged access to every in-scope system; non-human identities are assessed under SIAS-IAM-06. SecurityInspect Verified profile: VP-CLD (privileged access within the named cloud tenants or accounts).
Pass criteria
- 1.Every holder of a privileged role appears in the register with a justification, and the register has no holders that A1 did not find.
- 2.Standing holders of top-level administrative roles are within the limit in requirement 4.
- 3.Every sampled privileged task was performed with a separate administrative identity or through just-in-time elevation.
- 4.Every use of root or organization-owner accounts in the look-back period has a documented reason that requires that account.
- 5.No exploitable privilege-escalation path exists from non-privileged to privileged roles, other than documented and authorized elevation workflows.
- 6.No privileged right has gone unused for 90 days or more without a recorded justification.
- 7.The sampled role definitions grant no access beyond the documented duties.
Severity
High. The global escalation rules apply; in particular, a privilege-escalation path reachable without authentication from the internet is an authentication bypass and is escalated to Critical.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(4)(ii)(B), §164.312(a)(1)
- PCI DSS v4.0.1
- 7.2, 7.3
- Trust Services Criteria
- CC6.3
- ISO/IEC 27001:2022
- A.5.15, A.8.2, A.8.3
- Theme (SecurityInspect wording)
- least privilege and controlled privileged rights
SIAS-IAM-04 Periodic access review
- Mandatory
- Yes
- Severity
- Medium
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
Access that is no longer needed is found and removed on a regular cycle, including when a lifecycle event was missed.
Testable requirement
- The applicant must:
- 1.review privileged access to in-scope systems at least every 3 months, and all other access at least every 6 months;
- 2.base each review on the complete population of accounts and roles for the system (including local, third-party and non-human accounts), taken from a system-generated list dated at the start of the review;
- 3.have each review performed by the system owner or the users' managers, with no reviewer deciding on their own access;
- 4.record a decision (keep, change or remove) for every entry;
- 5.complete removals and changes within 5 business days for privileged access and 30 calendar days for other access;
- 6.keep review records for at least 12 months.
Applicability and scope
All scopes. Covers every in-scope system with user or role assignments. Not part of any SecurityInspect Verified profile.
Pass criteria
- 1.For every in-scope system, the most recent completed review of each type falls within its required interval before the assessment date.
- 2.Every reviewed population was complete.
- 3.No reviewer decided on their own access.
- 4.Every entry has a recorded decision.
- 5.Every sampled removal or change was completed within the limit in requirement 5.
- 6.A2 finds no "remove" decision whose access is still active.
Severity
Medium. The global escalation rules apply.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(4)(ii)(C)
- PCI DSS v4.0.1
- 7.2
- Trust Services Criteria
- CC6.2, CC6.3
- ISO/IEC 27001:2022
- A.5.18
- Theme (SecurityInspect wording)
- periodic confirmation that access remains appropriate
SIAS-IAM-05 Authentication strength and credential protection
- Mandatory
- Yes
- Severity
- High
- Applies
- All scopes
- SecurityInspect Verified profiles
- VP-APP
Control objective
Authentication secrets are hard to guess, resist reuse of leaked passwords, are protected against automated guessing and storage theft, and are never left at vendor defaults.
Testable requirement
- The applicant must:
- 1.require passwords of at least 15 characters where the password is the only factor and at least 8 characters where it is used with a second factor, and accept at least 64 characters, including spaces and all printable characters;
- 2.check new and changed passwords against a list of known compromised and commonly used passwords, and reject matches;
- 3.force a password change when compromise is suspected;
- 4.lock or throttle an account after no more than 10 consecutive failed sign-in attempts on every in-scope sign-in function;
- 5.change or disable vendor-default and initial credentials before a system is exposed to users or connected to a production network, and make temporary passwords unique per user and changed at first use;
- 6.where in-scope software stores user passwords, store them only as salted hashes produced by an adaptive, deliberately slow algorithm (for example Argon2id, scrypt, bcrypt or PBKDF2 with a high work factor);
- 7.keep shared secrets in a password manager or vault, never in documents, spreadsheets, tickets, chat messages or code;
- 8.transmit credentials only over encrypted connections and never in URLs. The applicant should not force periodic password changes without an indication of compromise.
Applicability and scope
All scopes. Covers every authentication mechanism for workforce and administrative access, and the sign-in functions of in-scope applications for their own users. For end-user passwords that an in-scope application manages itself, the length rule in SIAS-APP-03 testable requirement 3 applies instead of requirement 1 here, and a gap is recorded once, under SIAS-APP-03 (§2.11; the length values are open decision D-STD-APP-03). Session management and authorization logic in applications are assessed under SIAS-APP-03. SecurityInspect Verified profile: VP-APP (the named application's sign-in functions and its administrative authentication).
Pass criteria
- 1.Settings on the identity provider and on each in-scope sign-in function meet requirements 1, 2 and 4, as configured and as tested.
- 2.Throttling or lockout started at or before the tenth consecutive failure in every A2 test.
- 3.The known-compromised password was rejected in every A3 test.
- 4.No working default credentials were found.
- 5.Password storage in in-scope software meets requirement 6.
- 6.No credentials were found in the sampled shared locations.
- 7.No credentials are sent over unencrypted connections or in URLs.
Severity
High. Escalate to Critical under the global rules when working vendor-default credentials are found on an internet-facing asset (an authentication bypass) or credentials cross the internet in cleartext.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(5)(ii)(D), §164.312(d)
- PCI DSS v4.0.1
- 8.3, 2.2
- Trust Services Criteria
- CC6.1
- ISO/IEC 27001:2022
- A.5.17, A.8.5
- Theme (SecurityInspect wording)
- strength and protection of authentication secrets
SIAS-IAM-06 Non-human identities and workload credentials
- Mandatory
- No
- Severity
- High
- Applies
- Conditional — service accounts, API keys or workload identities access in-scope systems
- SecurityInspect Verified profiles
- VP-CLD
Control objective
Service accounts, API keys, tokens and workload identities are known, owned, limited to what they need, short-lived where possible and kept out of code.
Testable requirement
- The applicant must:
- 1.keep an inventory of non-human identities with access to in-scope systems, recording owner, purpose, systems reached, privileges, credential type, creation date and last rotation;
- 2.prevent interactive sign-in by service accounts wherever the platform allows it;
- 3.use short-lived, automatically issued credentials (for example workload identity federation or instance roles) instead of long-lived keys wherever the platform supports them, and record the reason wherever it does not;
- 4.rotate long-lived credentials at least every 365 days; rotate or revoke a credential that may have been exposed within 24 hours of discovery where it was in a location that is or was publicly accessible, and otherwise within 1 business day, and rotate it without delay when a person who knew the secret leaves (the same in SIAS-CRY-03 and SIAS-SDC-06);
- 5.store secrets in a secrets manager or the platform's protected store, never in source code, container images, build logs or plain configuration files in repositories;
- 6.scan source repositories and build pipelines for committed secrets, and revoke and rotate every secret found;
- 7.disable non-human credentials unused for 90 days;
- 8.grant non-human identities least privilege and include them in access reviews (SIAS-IAM-04).
Applicability and scope
Conditional — service accounts, API keys or workload identities access in-scope systems. Marking it not applicable needs a written rationale approved by the quality reviewer. A live secret found in source control, container images or pipelines is raised once: under SIAS-SDC-06 where that control is assessed, otherwise under this control (§2.11). This control scores the credential's inventory, ownership and rotation. SecurityInspect Verified profile: VP-CLD (non-human identities in the named cloud tenants or accounts and the pipelines that deploy to them).
Pass criteria
- 1.Every non-human identity found by A1 is in the inventory with an owner.
- 2.No long-lived credential is older than 365 days.
- 3.No credential unused for 90 days or more remains enabled.
- 4.No live secret was found in the scanned repositories, images or logs.
- 5.Service accounts cannot sign in interactively wherever the platform allows the restriction.
- 6.The privileges of every sampled non-human identity match its documented purpose.
- 7.Short-lived credentials are used wherever the platform supports them, or a justified reason is recorded.
Severity
High. Escalate to Critical under the global rules when a live secret that grants access to in-scope systems or to Restricted or other sensitive data (see SIAS-DAT-01) is exposed where unauthenticated parties can reach it, for example in a public repository.
Informative framework mappings
- HIPAA Security Rule
- §164.312(a)(1)
- PCI DSS v4.0.1
- 8.6
- Trust Services Criteria
- CC6.1, CC6.2
- ISO/IEC 27001:2022
- A.5.16, A.5.17, A.8.2
- Theme (SecurityInspect wording)
- control of system and service accounts
