Identity & Access Management¶
This policy decides who can get into what, and how they prove it's really them. For staff it comes down to strong unique sign-ins, MFA everywhere, using the password manager, and losing access the day you change roles or leave. Most of the policy is for IT, covering admin accounts, service accounts, and the identity machinery attackers target instead of guessing passwords.
Terms are defined in the Framework.
1. Identity lifecycle (joiner, mover, leaver)¶
| Ref | Requirement |
|---|---|
| IAM.1 | A formal registration and de-registration process MUST be maintained for all users, with records showing each change was authorised. |
| IAM.2 | Access MUST follow least privilege, the minimum needed for the role, and SHOULD be assigned via role groups rather than to individuals. |
| IAM.3 | Access MUST be reviewed and adjusted when someone changes role. |
| IAM.4 | On termination, access MUST be revoked promptly: same business day as a target, immediately for RESTRICTED systems. |
| IAM.5 | Joiner, mover, and leaver actions MUST be auditable, and leaver de-provisioning MUST be audited for completeness. |
| IAM.6 | System Owners MUST review access to RESTRICTED and personal-information systems at least annually. |
2. Authentication¶
| Ref | Requirement |
|---|---|
| IAM.7 | All system access MUST be authenticated, with strength proportionate to what it protects. |
| IAM.8 | Passwords MUST be at least 14 characters, or a passphrase, where the system allows. Complexity rules and forced periodic expiry MUST NOT be imposed where length and other controls are in place. This aligns with NIST SP 800-63B and CIS. |
| IAM.9 | A banned-password list MUST be enforced, and on-premises AD password protection MUST be set to Enforced, not Audit. |
| IAM.10 | MFA MUST protect all cloud and remote access and all administrative access. Legacy authentication and device-code sign-in flows MUST be blocked. |
| IAM.11 | Phishing-resistant MFA (FIDO2, Windows Hello for Business, or certificate-based) SHOULD be used for administrative and other high-privilege access. |
| IAM.12 | Weak second factors, SMS, voice, and email one-time codes, SHOULD be disabled in favour of authenticator or phishing-resistant methods. |
| IAM.13 | Accounts MUST lock after a small number of failed attempts, and sessions MUST re-authenticate after a suitable period of inactivity. |
| IAM.14 | Accounts unused for 180 days MUST be disabled where the system can enforce it. Shared and service mailboxes are an easily overlooked identity surface and MUST have interactive sign-in blocked unless there's a documented need. |
3. Credentials and the password manager¶
| Ref | Requirement |
|---|---|
| IAM.15 | Users MUST NOT share passwords with anyone, including IT. Where a shared secret is genuinely unavoidable, it MUST go through the password manager's shared vaults, never in plaintext. |
| IAM.16 | Users MUST NOT reuse work credentials on personal accounts, and SHOULD NOT rely on browser "remember password" features. |
| IAM.17 | The approved password manager (1Password) MUST be the standard tool for all staff, with vault access segregated so people, including IT, can only reach the secrets they need, and recovery-key custody documented. |
Vault segregation in IAM.17 matters because a shared password store with broad access concentrates risk. Access to a secret should track need, not job title.
4. Privileged access¶
| Ref | Requirement |
|---|---|
| IAM.18 | Administrative work MUST use separate, cloud-only admin accounts, never a person's day-to-day account. |
| IAM.19 | Privileged roles MUST be activated just-in-time through Privileged Identity Management. Standing privileged assignments MUST NOT be used except for documented break-glass accounts. |
| IAM.20 | Local administrator accounts MUST be managed by LAPS with unique, rotated passwords. Unmanaged local admin accounts MUST be removed. |
| IAM.21 | Privileged accounts MUST be protected against credential theft, for example via the Protected Users group and phishing-resistant MFA (IAM.11). |
| IAM.22 | Local admin rights on user devices MUST be minimised and elevated on request (Admin by Request), not granted standing. |
| IAM.23 | Break-glass accounts MUST exist, be tightly controlled, and have their activity monitored (11). |
5. Non-human identities¶
Service accounts, API keys, tokens, certificates, and AI agents are where identity risk now concentrates. They outlive the people who created them and rarely get the scrutiny human accounts do.
| Ref | Requirement |
|---|---|
| IAM.24 | Every non-human identity MUST have a named owner and be inventoried. |
| IAM.25 | Managed identities or group-managed service accounts MUST be used where supported. Where a static secret is unavoidable, it MUST be at least 32 characters, rotated on a schedule, and held in the approved secret store (for example Azure Key Vault), never in code, pipelines, or config files. |
| IAM.26 | Delegation and trust relationships (for example Kerberos constrained or resource-based delegation) MUST be justified, documented, and reviewed. Unnecessary service principal names MUST be removed. |
| IAM.27 | Certificate issuance MUST NOT allow requester-supplied subject names with authentication use unless approved and monitored. This closes a common privilege-escalation path to domain admin. |
| IAM.28 | AI agents that act on Holmes systems MUST follow these rules and the extra controls in 05 AI Systems. |
Developer token handling is detailed in 09 Secure Development.
6. Legal & jurisdictional notes¶
Access controls are a core safeguard under NZ IPP5, the Australian APPs, and GDPR Article 32. Least privilege and access review (IAM.2, IAM.6) are how Holmes shows it applies appropriate technical measures to personal information.
RESTRICTED systems holding US CUI or ITAR data may require US-person-only access, which IAM.3 and IAM.6 must accommodate for those systems.
Related policies¶
00 Framework, 01 Acceptable Use, 04 Cloud & Third-Party, 05 AI Systems, 09 Secure Development, 11 Logging & Monitoring.