3.5 IA
727 paragraphs across seven sections. Here is the structure and the key design decisions that distinguish this page from generic identity documentation.
Document structure
The 11 IA controls are grouped into four implementation bands rather than presented in numerical order. This grouping reflects how engineers actually implement them — identity management (3.5.1, 3.5.9) is an Active Directory and Entra ID administration problem; authentication requirements (3.5.2, 3.5.4, 3.5.11) are Conditional Access and protocol problems; password policy (3.5.5 through 3.5.10) is a Group Policy and application configuration problem; and MFA (3.5.3) is its own platform-by-platform configuration problem. Engineers reading a single group understand the full implementation scope without jumping between unrelated controls.
Section 0 — the ISO 27001 Annex A mapping table — makes a distinction that matters for evidence planning. Annex A 5.16 (Identity management) and 5.17 (Authentication information) are often treated as the same control in ISMS implementations. They are not. 5.16 is about who accounts are and how their lifecycle is managed — identity provisioning, de-provisioning, and identifier reuse. 5.17 is about how authentication secrets (passwords) are managed — their composition, storage, and transmission. Conflating them produces evidence packs that satisfy one Annex A control but leave the other unsupported.
Group D — the MFA platform configuration guide — is the most operationally detailed section in the page and the one most likely to be used by an engineer who has been asked to configure a new platform for compliance. The six Conditional Access policy definitions are specific enough to implement directly. The AWS IAM MFA section, the Microsoft 365 section, and the VPN/Linux/on-premises section cover the platforms that most NIST 800-171 environments operate. The MFA coverage verification procedure table gives the engineer the exact steps to produce EV-D05 — a named evidence item that must exist before the assessment.
Section 3 — the PKI requirements section — explains the relationship between PKI and IA controls that is often documented separately or not at all. Device certificates support 3.5.1 (identify devices in Conditional Access). SSH user certificates support 3.5.4 (replay-resistant privileged access via PAM). The PKI architecture table defines five distinct CA roles, which is more granular than most organisations document — this level of specificity is what a C3PAO assessor expects to see in an SSP system description.
The password policy table — a deliberate design choice
The password policy specification table covers three account categories (standard, privileged, service) across 12 parameters. Most organisations produce a single-column password policy document. The three-column format here exposes the differentiation that NIST 800-171 implies but does not spell out: the standard for privileged accounts is materially stricter (longer passwords, shorter lockout threshold, no standard-user SSPR, FIDO2-only MFA), and service account management is entirely separate from human account management (PAM vault storage, no interactive login, programmatic rotation). A C3PAO assessor will specifically ask about service account management — it is one of the most consistently weak areas in CMMC assessments.
The note on password expiry policy deserves explicit acknowledgement here: the document recommends no mandatory expiry when MFA is enforced, following NIST SP 800-63B guidance. This is correct but may conflict with some organisations' existing policies or auditor expectations trained on older standards. The rationale is in the document — forced rotation produces weaker passwords, and MFA compensates for the risk that a static password might be compromised over time. If your assessor is unfamiliar with this NIST guidance, point them to SP 800-63B Section 5.1.1.2.
The six common findings — all from real assessment patterns
Finding two — TOTP for privileged accounts — is the most frequently argued finding in CMMC Level 2 assessments. The control says MFA; organisations deploy TOTP; assessors cite 3.5.4 (replay resistance) as the additional requirement that TOTP does not satisfy as robustly as FIDO2. The document makes this argument explicitly in the MFA method strength hierarchy box, which is the right place for engineers to read it before choosing an MFA method rather than after a finding.
Finding six — SMS OTP remaining as a fallback option — is operationally subtle. When Entra ID has SMS OTP as an available method (even if 98% of users use the authenticator app), the assessment considers the weakest available method as the effective authentication strength. This is because an attacker who has compromised a user's account credentials can trigger a method change to SMS and then execute a SIM-swap. Remove SMS entirely from Entra ID Authentication methods before the assessment — the path is Entra ID → Authentication methods → Policies → SMS → disable. This is a two-minute configuration change that eliminates a potential critical finding.
Cross-linking in Confluence
The AT-IA page should carry active cross-links to five pages. Link to AT-AC (the access control family operationalises the permissions that IA defines — identity is who you are; access control is what you can do). Link to AT-SC-ENC (the cryptographic storage of passwords in 3.5.10 uses the same FIPS-validated algorithm requirements documented in the encryption section). Link to FC-03 (the all-staff visible user access control page — AT-IA is the technical backend, FC-03 is the behavioural frontend). Link to the Access Control Policy (the policy document that defines account management obligations, which this page implements technically). And link to AT-SC-ARC (the management plane separation in 3.13.3 depends on the privileged account model defined here — the dual-account architecture connects both families).