6.1 Identity Proofing, Authentication, Authorization, and Accountability

The IAM Chain of Trust

Identity and access management begins before a password, token, badge, or biometric is issued. The organization first decides how much confidence it needs that a subject is who it claims to be. That subject may be an employee, contractor, customer, partner, device, workload, or service account. The proofing method should match the harm that could occur if the identity is wrong.

Identity proofing is the enrollment decision. It may use government documents, HR records, in-person checks, verified business sponsorship, device attestation, or automated evidence validation. The key governance question is not whether proofing is convenient. The key question is whether the proofing process creates enough identity assurance for the business process being protected.

Authentication is the later act of proving control of an enrolled identity. It uses factors such as something known, something possessed, something inherent, somewhere present, or something behaviorally observed. Strong authentication reduces impersonation risk, but it does not decide whether the authenticated subject should access a record, approve a payment, or administer a server.

Authorization is the policy decision after identity is known with sufficient confidence. It maps subjects to permissions through roles, attributes, labels, risk signals, ownership rules, and business approvals. Authorization should be specific enough to support least privilege and separation of duties. Broad grants are easy to operate, but they create toxic combinations, standing privilege, and poor audit defensibility.

Accountability is the ability to trace actions to the responsible identity or process. It depends on unique accounts, synchronized time, reliable logs, tamper resistance, and review. Shared accounts, generic administrator IDs, and missing audit trails destroy accountability even if authentication was strong. A control that cannot be attributed is weaker during investigations, compliance reviews, and disciplinary processes.

A mature IAM program treats identity as a lifecycle object. A new hire may be proofed by HR, assigned baseline access through a role, elevated through manager approval, monitored through logs, and removed when employment ends. A contractor may need stricter expiration, sponsor recertification, and limited access because the relationship is temporary. A production administrator may need privileged access management, just-in-time elevation, and session recording.

The authentication strategy should also reflect threat and usability. Password-only access to a payroll system is weak because a stolen credential can expose sensitive data and enable fraud. MFA with phishing-resistant authenticators is stronger for administrative and high-value access. Adaptive controls may step up authentication when the login comes from a new device, impossible travel pattern, risky network, or unusual time.

Authorization must be owned by the business as well as security. Security teams can design policy engines and control frameworks, but data owners and process owners know which access is appropriate. The best pattern is clear ownership, documented approval criteria, automated enforcement, and review evidence. The worst pattern is ticket approval without context, where managers approve access they do not understand.

Least privilege is not simply the smallest technical permission set. It is the minimum access needed for a defined business purpose, for the right duration, under the right conditions, with monitoring proportional to risk. A developer who needs production logs for two hours does not need permanent shell access to every production host. A finance analyst who approves vendors should not also create vendors unless a compensating control exists.

A CISSP answer often turns on separating the steps. If a user is authenticated but cannot access a file, the issue is likely authorization. If an action cannot be tied to a person because an admin account is shared, the issue is accountability. If a remote contractor was issued an account without sponsor validation, the issue began at proofing. Good IAM governance names the failed step and fixes it at the source.

Lifecycle Control Checklist

• Establish identity proofing requirements by role, data sensitivity, and transaction risk.
• Require unique identities for people and managed non-human subjects unless a formally approved exception exists.
• Use MFA for privileged, remote, sensitive, and high-impact access, with stronger methods for higher risk.
• Assign access through roles or policies where possible, then handle exceptions with owner approval and expiration.
• Log authentication, authorization, privilege elevation, and sensitive actions with enough detail for investigation.
• Review access regularly, remove stale entitlements, and test termination workflows.

The managerial view is to avoid confusing a technology with the control objective. Biometrics, smart cards, certificates, passwords, and passkeys are mechanisms. The objective is trustworthy identity, appropriate authorization, reliable accountability, and timely lifecycle change. When an organization can explain why each identity exists, why each entitlement is needed, who approved it, and when it will be reviewed, IAM becomes a governance system instead of an account database.