User and Service Account Provisioning

Why User and Service Account Provisioning Matters
Every piece of software needs identities to operate: human users who log in and non-human service accounts that let applications, batch jobs, APIs, and microservices authenticate to databases, message queues, cloud services, and each other. If provisioning (creating, assigning privileges to, maintaining, and eventually removing these accounts) is done poorly, you get orphaned accounts, over-privileged services, shared or hard-coded credentials, and no accountability. Attackers love these conditions because a forgotten service account with a static password and admin rights is a silent, high-value foothold. In the CSSLP body of knowledge, account provisioning sits inside Domain 2: Secure Software Requirements because it must be defined before design and coding begin. The exam expects you to treat provisioning as a requirements-level control tied to confidentiality, integrity, availability, authentication, authorization, accountability (auditing), and non-repudiation.

What It Is
Provisioning is the complete identity lifecycle for an account: request, approval, creation, entitlement (role/permission) assignment, periodic review and recertification, modification when roles change, and de-provisioning (disable, then delete) when the account is no longer needed.

User accounts represent people (employees, contractors, customers, administrators). They are typically provisioned through an Identity and Access Management (IAM) or Identity Governance and Administration (IGA) system, often triggered automatically by an HR system event (hire, transfer, termination).

Service accounts represent software, not people. Examples include a web application connecting to a database, a scheduled job, a CI/CD pipeline, a container, or a cloud workload. They are interactive-logon-disabled, used by processes, and frequently long-lived. Because no human "owns" the session, they require explicit assignment of a human owner, strict least privilege, and managed (ideally rotated or ephemeral) credentials.

How It Works – Key Requirements to Specify
1. Identification and uniqueness: Every account, human or service, must be unique and attributable. No shared accounts; shared accounts destroy accountability and non-repudiation. Default and vendor accounts must be renamed, disabled, or removed.
2. Least privilege: Accounts receive only the minimum permissions required for their function. Service accounts should never run as root/Administrator or use the database sa account. Separate accounts for separate functions.
3. Need-to-know and separation of duties: No single account should be able to request, approve, and provision access. Developers should not hold production service account credentials.
4. Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC): Assign entitlements to roles, then roles to accounts, so provisioning is consistent and reviewable.
5. Approval workflow: Access requests require documented business justification and owner approval, logged for audit.
6. Credential management: Strong authentication (MFA for humans, certificates/keys/managed identities for services), no hard-coded passwords in source code or configuration files, secrets stored in a vault or secrets manager, and automated rotation. Prefer cloud managed identities or short-lived tokens over static secrets.
7. Ownership and documentation: Each service account must have a named owner, a documented purpose, and a defined review date.
8. Periodic access review / recertification: Owners attest that accounts and privileges are still required; stale or orphaned accounts are removed.
9. Timely de-provisioning: Terminated users and decommissioned applications must have accounts disabled immediately (automated via HR feed where possible) and deleted after a retention period. Orphaned service accounts are a top finding in audits.
10. Logging and monitoring: Provisioning events and account usage are logged, protected from tampering, and monitored for anomalies such as a service account performing an interactive login.
11. Privileged Access Management (PAM): Administrative and privileged service accounts are checked out, brokered, session-recorded, and rotated through a PAM solution.
12. Automation and standards: Use SCIM, SAML/OIDC federation, directory services, and Infrastructure as Code to make provisioning repeatable, auditable, and less error-prone. Automation also reduces "privilege creep" when people change roles.

Security Principles Being Enforced
Least privilege, separation of duties, defense in depth, complete mediation, fail secure (disable rather than grant on error), psychological acceptability (provisioning should be easy enough that users don't work around it), and accountability. These principles frequently appear as the "correct" rationale in exam answers.

Common Weaknesses the Exam Tests
Hard-coded credentials in code; shared or generic accounts; service accounts with domain admin rights; accounts never reviewed or disabled after termination (orphaned accounts); privilege creep from accumulated roles; default vendor passwords; granting access on the basis of convenience rather than documented business need; manual, undocumented provisioning with no audit trail.

Exam Tips: Answering Questions on User and Service Account Provisioning
Tip 1 – Think "requirements phase": If a question asks when provisioning rules should be defined, the answer is during requirements gathering, not after deployment. Security requirements for identity and access must be captured up front and traced through design, implementation, and testing.
Tip 2 – Least privilege almost always wins: When choices include granting broad rights for convenience versus granting the minimum necessary, pick least privilege. For service accounts specifically, look for the option that creates a dedicated, restricted account rather than reusing an administrative or user account.
Tip 3 – Accountability requires uniqueness: Any option involving shared accounts or generic logins is wrong if the question mentions auditing, non-repudiation, or traceability.
Tip 4 – Service account red flags: Hard-coded passwords, passwords that never expire, interactive logon enabled, no named owner, and excessive privileges are the classic wrong answers. The right answer typically involves secrets management, rotation, managed identities, PAM, and documented ownership.
Tip 5 – De-provisioning is part of provisioning: If a scenario describes an employee who left or an application that was retired, the "most important" or "first" action is to disable the account promptly. Orphaned accounts are the risk the exam wants you to identify.
Tip 6 – Prefer automation and centralization: Answers referencing IAM/IGA, HR-driven automated provisioning, RBAC, federation, and periodic recertification are more mature than manual, ad hoc processes. The CSSLP favors repeatable, auditable controls.
Tip 7 – Separation of duties: If one person or process can both request and approve access, or developers hold production credentials, that is the vulnerability. The fix is separating roles and using an approval workflow.
Tip 8 – Read for the keyword: "Confidentiality" points toward access control and least privilege; "accountability" or "non-repudiation" points toward unique IDs and logging; "availability" may point toward avoiding single points of failure such as an account whose expiring password breaks a production service (another reason for managed rotation).
Tip 9 – Eliminate extremes: Options that say "delete all service accounts" or "give the application full admin so it always works" are distractors. The best answer balances functionality with controlled, minimal, monitored access.
Tip 10 – Use the "BEST / MOST / FIRST" lens: CSSLP questions often ask for the best or first step. For provisioning, the first step is usually defining the requirement (who needs what access and why); the best control is typically the one that enforces least privilege with auditability.

Quick Review Summary
Provisioning covers the full account lifecycle for both human users and non-human service accounts. Define requirements early; enforce unique identities, least privilege, RBAC/ABAC, approval workflows, strong credential management (no hard-coding, vaulting, rotation, managed identities), named ownership, periodic recertification, prompt de-provisioning, and comprehensive logging. In exam scenarios, choose the option that minimizes privilege, preserves accountability, automates and centralizes control, and removes access as soon as it is no longer needed.