Identity Lifecycle and IAM Architecture

Introduction

Identity and access management (IAM) is not merely a login system. It is the coordinated set of policies, processes, data, and technologies used to establish who or what an identity represents, issue suitable credentials, grant appropriate access, respond to change, and retain evidence of every significant decision.

A digital identity may represent an employee, customer, partner user, software workload, or physical device. These identity classes do not follow identical procedures: an employee may be verified by human resources, while a device may be verified through a manufacturer certificate. Nevertheless, each class requires a controlled lifecycle covering establishment, enrollment, provisioning, credential management, access modification, recovery, suspension, deprovisioning, and audit.

Weak lifecycle controls create orphaned accounts, excessive privileges, fraudulent recovery, unmanaged cryptographic keys, and incomplete audit evidence. Consequently, lifecycle design is foundational to secure full-stack systems.

Learning Objectives

After studying this chapter, students should be able to:

1. Distinguish subjects, identities, accounts, credentials, entitlements, and sessions.
2. Model lifecycle processes for workforce, customer, partner, service, and device identities.
3. Explain identity proofing, enrollment, provisioning, credential issuance, recovery, suspension, and deprovisioning.
4. Design an IAM architecture using authoritative sources, identity providers, governance services, policy engines, and audit systems.
5. Evaluate credential binding, delivery, activation, rotation, and revocation controls.
6. Calculate and interpret lifecycle performance measures.
7. Apply governance, privacy, and regulatory principles to identity data.

1. Identity as a Managed Security Object

An identity is a digital representation of a subject. The subject may be a person, organization, software process, device, or other entity. Several related concepts must remain distinct:

• Subject: The person or entity requesting or receiving access.
• Digital identity: A collection of attributes representing the subject within a defined context.
• Account: A record in a particular system through which the identity acts.
• Credential: Evidence used to authenticate an identity, such as a password, private key, passkey, or smart card.
• Entitlement: A permission, role, group membership, license, or other access grant.
• Session: A time-bounded interaction established after authentication.

One identity can have multiple accounts, and one account may possess multiple credentials. For example, an employee identity maintained by an enterprise may be linked to accounts in an identity provider, source-code platform, payroll system, and cloud environment. Deleting only one account does not deprovision the identity completely.

An IAM lifecycle must therefore manage relationships among identities, accounts, credentials, and entitlements rather than treating them as interchangeable records.

2. The Identity Lifecycle

A lifecycle is a state-and-transition model. Transitions are triggered by authoritative events, approved requests, risk findings, expiration, or administrative decisions.

Figure: Identity lifecycle events and evidence flow into an audit repository. An active identity may be deprovisioned directly; suspension is not a mandatory intermediate state.

The model is not strictly linear. Access changes and credential rotation can occur repeatedly while an identity is active. Recovery may return an identity to active status after successful verification and credential rebinding. Suspension is a reversible restriction used for temporary risk, leave, investigation, or uncertain status. Deprovisioning is normally terminal within the operational system, although records may be retained according to legal and audit requirements.

2.1 Identity proofing

Identity proofing establishes sufficient confidence that a claimed identity corresponds to the intended real-world or organizational subject. It generally involves:

1. Resolution: Determining that the claimed identity refers to a unique subject in the relevant population.
2. Evidence validation: Checking whether evidence is genuine, current, and acceptable.
3. Attribute verification: Confirming relevant claims through authoritative or reliable sources.
4. Binding: Associating the verified subject with a digital identity record.

Proofing strength should be proportional to risk. A newsletter account may require only email verification, whereas access to regulated financial records may require stronger documentary, biometric, organizational, or in-person evidence. Collecting more data is not automatically better: unnecessary evidence increases privacy and breach risk.

2.2 Enrollment

Enrollment registers the identity in an IAM domain and establishes identifiers, attributes, contacts, consent records, and authentication methods. Proofing asks, “How confidently do we know the claimant?” Enrollment asks, “How will this identity be represented and managed here?”

Identifiers should be stable, unique within their namespace, and preferably non-semantic. Reusing an employee number or email address can wrongly connect a new person to historical access. Internal immutable identifiers should therefore be separated from changeable usernames and display names.

2.3 Provisioning

Provisioning creates or updates accounts, attributes, roles, groups, and policy relationships in target systems. It may be:

• Push-based: A governance system sends changes to targets, commonly through APIs or the System for Cross-domain Identity Management (SCIM).
• Pull-based: A target periodically obtains identity data.
• Just in time (JIT): An account is created when a federated user first accesses the service.
• Manual: An administrator performs the action under an approved procedure.

JIT provisioning improves convenience but does not remove governance obligations. The organization must still define who may enter, what initial access is granted, and how the account is later disabled or removed.

2.4 Active use and access change

Active identities authenticate, establish sessions, and exercise entitlements. Access changes arise from job transfers, purchases, contract changes, risk signals, device posture, or application deployment.

Common grant models include:

• Birthright access: Automatically assigned from reliable attributes, such as employment type.
• Request-and-approval access: Granted after an accountable owner approves a defined need.
• Role-based access control (RBAC): Permissions are grouped by organizational or functional role.
• Attribute-based access control (ABAC): Policies evaluate subject, resource, action, and environmental attributes.
• Just-in-time privilege: Elevated access is issued only when needed and expires automatically.

Access changes should enforce least privilege, separation of duties, expiration, and independent review for sensitive privileges. A transfer should not merely add new access; obsolete access must also be removed.

2.5 Recovery

Recovery restores control when a credential is lost, locked, expired, or suspected of compromise. Recovery is effectively another proofing process and must not be weaker than the authentication it replaces. An attacker who cannot defeat a passkey may still succeed if a help desk resets it after answering public knowledge questions.

Secure recovery may use pre-enrolled recovery codes, verified possession of another authenticator, supervised organizational validation, or delayed high-risk recovery with notifications. Following recovery, compromised credentials and active sessions should be revoked, a new credential should be bound, and the event should be audited.

2.6 Suspension and deprovisioning

Suspension temporarily blocks authentication or authorization while preserving the identity and evidence. Typical triggers include extended leave, fraud indicators, certificate quarantine, contract disputes, or repeated policy violations.

Deprovisioning removes operational access because the relationship has ended, the identity was created in error, or the represented entity has been retired. A normal termination can move directly from active to deprovisioned. Deprovisioning should disable authentication, revoke sessions and credentials, remove entitlements, transfer owned resources, stop scheduled jobs where applicable, and preserve required records.

3. Lifecycle Controls Across Identity Classes

A sound architecture applies every lifecycle phase to all identity classes while adapting evidence and controls to the represented subject.

3.1 Establishment, enrollment, and credentials

A service identity is not proofed like a person. Its legitimacy is established through controlled creation, ownership, deployment provenance, and workload attestation. Similarly, device proofing may depend on supply-chain evidence and a hardware root of trust rather than human documents.

3.2 Change, recovery, suspension, and deprovisioning

Ownership is crucial. Partner, service, and device identities should have accountable sponsors or owners and review dates. Otherwise, technically active identities can outlive their business purpose.

4. Credential Issuance and Management

A credential lifecycle must address more than initial generation. It comprises selection, binding, secure delivery, activation, use, rotation, recovery, suspension, and revocation.

4.1 Selection and generation

Credential type should match the threat model. Phishing-resistant authenticators such as passkeys or hardware security keys are preferable for privileged and high-risk users. Workloads and devices generally require cryptographic credentials suitable for automated operation.

Private keys should be generated in a trusted environment and protected against extraction where feasible, such as in a hardware security module, trusted platform module, secure enclave, or managed key service. Shared secrets should be unique, randomly generated, access-controlled, and never embedded in source code.

4.2 Binding

Binding associates a credential with the correct identity record. Before binding, the issuer must authenticate or proof the claimant at an assurance level appropriate to the credential’s power. The binding record should include:

• identity identifier;
• credential identifier or public-key reference;
• credential type and assurance characteristics;
• issuer and issuance time;
• activation and expiration times;
• device or hardware binding where relevant;
• status, such as pending, active, suspended, or revoked.

For public-key credentials, the private key should remain with its holder or protected service; the IAM system normally stores the public key or certificate relationship.

4.3 Secure delivery

Delivery must prevent interception and substitution. A credential may be delivered through an authenticated in-person process, a mutually authenticated management channel, a device-enrollment protocol, or separated channels for token and activation information. Sending a reusable password and its activation link through the same unverified email channel provides weak protection.

When credentials are generated centrally, temporary material should be encrypted in transit, displayed minimally, and deleted after retrieval. Prefer protocols in which the holder generates the private key locally so that it never needs delivery.

4.4 Activation

Activation confirms that the intended holder received and controls the credential. It may require a one-time activation code, possession test, administrator approval, personal identification number, or cryptographic challenge-response. Initial passwords should be temporary and changed at first use. Unactivated credentials should expire after a short, defined interval.

4.5 Rotation and renewal

Rotation replaces credential material while preserving authorized identity continuity. It may be triggered by expiration, policy, personnel change, algorithm migration, or suspected exposure. Rotation must be coordinated so that dependent systems do not fail.

A safe automated rotation often follows an overlap pattern:

1. Create and bind the new credential.
2. Distribute its public or verification material.
3. Activate and test the new credential.
4. Permit a controlled overlap if operationally necessary.
5. disable and revoke the old credential.
6. Confirm that no workload still depends on it.

Routine forced password changes without evidence of compromise can encourage predictable passwords. Rotation policies should reflect credential type, risk, compromise evidence, and applicable standards rather than applying one rule to every authenticator.

4.6 Revocation

Revocation invalidates a credential before its scheduled expiration. It is required after compromise, identity termination, device loss, unauthorized issuance, or key replacement. Effective revocation requires enforcement by all relying systems.

For certificates, systems may consult certificate revocation lists or online status services. For tokens, short lifetimes reduce the window of exposure; refresh tokens and server-side sessions should also be revoked. For distributed offline systems, immediate revocation may be impossible, making short validity periods and periodic connectivity important design controls.

Revoking a credential is not identical to deprovisioning an identity. A user may lose one authenticator and receive another while retaining authorized access. Conversely, deprovisioning should revoke every relevant credential and session.

5. IAM Architecture

A modern IAM architecture separates authoritative data, lifecycle governance, authentication, authorization, enforcement, and evidence collection.

5.1 Core components

1. Authoritative sources: HR systems, customer registries, contract systems, workload registries, and asset inventories provide lifecycle facts.
2. Identity governance and administration (IGA): Coordinates provisioning, approvals, role management, access reviews, and policy compliance.
3. Identity provider (IdP): Authenticates subjects and issues assertions or tokens.
4. Directories and identity stores: Maintain identifiers, attributes, account links, and group relationships.
5. Credential and key infrastructure: Includes passkey services, public key infrastructure, hardware security modules, and secret managers.
6. Policy decision point: Evaluates access policy using reliable attributes and context.
7. Policy enforcement point: An application, API gateway, operating system, or network control that enforces the decision.
8. Privileged access management (PAM): Controls administrative accounts, elevation, credential checkout, and privileged session recording.
9. Audit and security analytics: Collects protected events for investigation, compliance, and anomaly detection.

An architecture should avoid making each application an independent identity authority. Centralized governance and federation reduce inconsistency, although applications remain responsible for local authorization and secure session handling.

5.2 Federation and protocols

Federation allows one security domain to rely on another domain’s authentication assertions. OpenID Connect commonly supports user authentication over OAuth 2.0, while Security Assertion Markup Language (SAML) remains common in enterprise federation. OAuth 2.0 is principally an authorization framework; an OAuth access token alone should not be treated as proof of user authentication without the appropriate authentication protocol and validation.

SCIM supports cross-domain identity provisioning. WebAuthn and FIDO2 support phishing-resistant public-key authentication. X.509 certificates are widely used for devices, workloads, and mutually authenticated communications. Protocol adoption does not by itself produce sound governance: trust configuration, claim validation, key management, and lifecycle integration remain necessary.

5.3 Event-driven orchestration and reconciliation

Lifecycle automation should respond promptly to authoritative events. For example, an HR termination event may trigger account disablement, token revocation, group removal, and resource transfer.

Event delivery can fail. Therefore, event-driven workflows should be complemented by periodic reconciliation. Reconciliation compares the intended state held by the authority or governance platform with the actual state in target systems. Differences generate repair actions or investigations. This combination provides both speed and eventual correction.

Automation should be idempotent: repeating an operation should not create duplicate accounts or restore removed access. Workflows also need retry limits, failure queues, accountable escalation, and transaction identifiers linking actions across systems.

6. Auditability and Lifecycle Metrics

Audit records should capture the actor, subject, action, target, decision, time, source, result, and relevant policy or approval reference. Time synchronization is necessary for reliable event reconstruction. Logs should be protected against unauthorized modification, access-controlled, retained for defined periods, and minimized to avoid recording unnecessary credentials or personal data.

Evidence flows from lifecycle systems into audit repositories—not from the repository into operational lifecycle stages. Audit systems may generate alerts or findings, but the original evidentiary direction remains from actions and decisions to protected records.

6.1 Orphan-account rate

At a defined observation time, the orphan-account rate is:

where O is the number of active accounts lacking a valid owner or active authoritative identity, and N is the total number of active accounts examined. Both are account counts measured for the same scope and time. The metric identifies governance weakness but does not directly measure the privileges or risk of each account.

6.2 Deprovisioning latency

For identity i, deprovisioning latency is:

where t_e,i is the timestamp of the authoritative end event and t_d,i is the timestamp at which required access became ineffective. The timestamps must use the same time basis. If systems complete at different times, policy should define whether t_d,i means first disablement, loss of critical access, or completion across all in-scope systems.

A simple aggregate exposure measure is:

where E is measured in identity-hours when latency is measured in hours. It is an operational exposure proxy, not a probability of breach.

Worked example: termination control performance

Eight terminated workforce identities have complete deprovisioning latencies of 1, 2, 3, 5, 8, 10, 20, and 23 hours.

The total exposure proxy is:

The mean latency is 72 ÷ 8 = 9 hours. If the service objective is completion within 4 hours, three of eight cases comply, giving 3 ÷ 8 × 100% = 37.5%. If the mandatory limit is 24 hours, all eight comply. The two results are not contradictory: they measure performance against different thresholds.

Managers should also monitor privileged-account latency, failed workflow rates, stale credentials, certification completion, recovery fraud, and device quarantine time. Averages should be supplemented by percentiles and maximum values because a small number of extreme delays can create substantial risk.

7. Illustrative Case: Northstar Digital Platform

Background

Northstar is a fictional software company operating a subscription platform. It manages 1,200 employees, two million customer identities, 600 partner users, 4,000 service identities, and 18,000 managed devices.

Problem

Each application created accounts independently. Employee transfers accumulated old roles, customer recovery relied on weak security questions, partner accounts had no expiration, deployment secrets remained valid indefinitely, and retired devices retained certificates. Termination evidence was scattered across application logs.

Analysis

The company’s main error was treating IAM as workforce single sign-on rather than as a multi-class lifecycle system. HR was authoritative only for employees; it could not govern customers, workloads, or devices. Moreover, disabling an IdP account did not revoke application sessions, cloud keys, or device certificates.

Approach and solution

Northstar established separate authoritative sources: HR for workers, the customer platform for customers, a sponsorship registry for partners, a workload catalog for services, and an asset platform for devices. All records used immutable internal identifiers and accountable ownership.

The company implemented event-driven lifecycle orchestration with nightly reconciliation. Employee termination directly triggered account disablement, session and token revocation, group removal, source-code ownership transfer, and privileged credential invalidation. Partner accounts received contract-aligned expiration dates. Customer recovery replaced knowledge questions with passkeys, recovery codes, risk checks, and notifications.

Service identities were issued short-lived workload certificates through the deployment platform. Private keys were generated within the workload environment, avoiding central delivery. Rotation used brief overlap followed by verified revocation. Devices were enrolled through management software using asset records and attestation; lost devices were quarantined, certificates revoked, and remote-wipe outcomes recorded.

All lifecycle systems sent signed or integrity-protected events to a central audit platform. Dashboards reported deprovisioning latency, orphan accounts, stale certificates, unowned services, recovery anomalies, and reconciliation failures.

Outcome

Within six months, Northstar reduced unowned service identities, eliminated non-expiring partner access, and obtained end-to-end termination evidence. Some legacy applications could not process real-time revocation, so the company shortened session lifetimes and prioritized replacement. This illustrates that architectural improvement often requires compensating controls during migration.

Learning points

• Each identity class requires its own authority and evidence model.
• Disabling a central account does not automatically revoke every credential or session.
• Automation must be backed by reconciliation and failure handling.
• Credential lifecycle controls must include binding, delivery, activation, rotation, and revocation.
• Audit evidence must cover decisions and outcomes, not merely login events.

8. Governance, Ethics, and Regulation

Identity systems process sensitive data and can determine whether people receive employment, services, or essential resources. Governance must address security, privacy, fairness, accountability, and due process.

Data minimization limits collected attributes to those necessary for stated purposes. Purpose limitation prevents identity evidence collected for authentication from being reused incompatibly. Retention rules should distinguish operational identity records from legally required audit evidence. Data-subject requests and account deletion may be constrained by fraud-prevention, contractual, or statutory retention duties, but such constraints should be documented rather than used to retain data indefinitely.

Proofing methods may disadvantage people lacking conventional documents, stable addresses, modern devices, or accessible biometric characteristics. Organizations should provide secure alternative channels and test processes for accessibility and disparate failure rates.

Administrative power also requires controls. Privileged actions should use strong authentication, just-in-time elevation, separation of duties, and independent audit. Break-glass accounts need narrow scope, protected credentials, alerting, testing, and post-use review.

Regulatory obligations vary by jurisdiction and sector. Relevant requirements may include privacy law, financial customer verification, health-information safeguards, payment security, records retention, and breach notification. Compliance frameworks should inform risk management but should not be mistaken for complete security.

9. Contemporary Developments and Design Challenges

Passwordless authentication reduces reliance on shared secrets, but organizations must still solve enrollment, cross-device use, account recovery, and authenticator revocation. Decentralized and verifiable credential systems can give holders more control over claims, although governance, issuer trust, correlation risk, and revocation remain difficult.

Cloud-native environments increasingly use workload identity and short-lived credentials rather than long-lived API keys. Device identity is also becoming central to zero-trust architectures, where authorization considers user identity, workload identity, device posture, resource sensitivity, and current context.

Machine learning can identify unusual provisioning, recovery, or access patterns. However, AI-generated risk scores should not silently suspend users without explainability, review, and appeal procedures. Training data may reproduce historical bias, and attackers may manipulate behavioral signals. AI is therefore a decision-support mechanism, not a substitute for authoritative lifecycle data and accountable policy.

Persistent challenges include legacy applications, inconsistent identifiers, merger-related duplicates, offline devices, delayed source events, cross-border privacy restrictions, and protocol misconfiguration. Effective IAM architecture anticipates partial failure and provides reconciliation, observability, manual escalation, and tested recovery.

10. Recommended Engineering Practices

• Assign an authoritative source and accountable owner to every identity class.
• Use immutable internal identifiers and prohibit identifier reuse.
• Apply risk-based proofing and collect only necessary evidence.
• Automate provisioning and deprovisioning, but reconcile intended and actual state.
• Remove obsolete access during transfers rather than only adding new access.
• Prefer phishing-resistant authentication and short-lived workload credentials.
• Document credential binding, delivery, activation, rotation, and revocation procedures.
• Revoke sessions and credentials as well as disabling accounts.
• Give partner, service, and device identities explicit expiration or review dates.
• Protect audit records and connect approvals to resulting technical actions.
• Test termination, recovery, certificate revocation, and break-glass processes regularly.
• Measure latency and exceptions by risk category, not only by organization-wide averages.

Chapter Summary

Identity lifecycle management governs the complete progression of a digital identity from proofing and enrollment through provisioning, active use, access change, recovery, suspension, and deprovisioning. Active identities may transition directly to deprovisioned status during normal termination; suspension is a reversible state, not a mandatory step.

Workforce, customer, partner, service, and device identities require the same categories of lifecycle control but use different authoritative evidence, credentials, recovery methods, and termination triggers. Credential management must explicitly address secure generation, identity binding, delivery, activation, rotation, and revocation.

A defensible IAM architecture integrates authoritative sources, governance services, identity providers, credential infrastructure, policy decision and enforcement points, target applications, and protected audit repositories. Event-driven automation provides speed, while reconciliation detects missed or inconsistent changes. Metrics such as orphan-account rate and deprovisioning latency help evaluate control performance but must be interpreted in their defined scope. Effective IAM also requires privacy, accessibility, accountable administration, and careful governance of automated risk decisions.

Key Terms

ABAC: Authorization model that evaluates attributes of subjects, resources, actions, and context.

Authoritative source: System accepted as the reliable origin of a defined identity fact or lifecycle event.

Binding: Verified association between an identity and a credential, account, or identifier.

Credential: Evidence used to authenticate an identity.

Deprovisioning: Removal of operational accounts, credentials, sessions, and entitlements when access is no longer justified.

Digital identity: Digital representation of a person, device, workload, organization, or other subject.

Enrollment: Registration of an identity, its attributes, and its authentication methods in an IAM domain.

Entitlement: Permission, role, group membership, license, or other access grant.

Federation: Trust arrangement in which one domain relies on identity assertions from another.

Identity proofing: Process of establishing confidence that a claimed identity corresponds to the intended subject.

IGA: Identity governance and administration capabilities for provisioning, approvals, reviews, roles, and compliance.

Orphan account: Active account without a valid owner or corresponding active authoritative identity.

Provisioning: Creation or update of accounts, attributes, credentials, and access relationships.

RBAC: Authorization model that assigns permissions through roles.

Reconciliation: Comparison of intended identity state with actual state in target systems.

Recovery: Controlled restoration of identity access after credential loss, lockout, or compromise.

Revocation: Invalidation of a credential, token, session, or entitlement before normal expiration.

Service identity: Identity assigned to software, a workload, automation, or a machine-operated process.

Suspension: Temporary and reversible restriction of identity access.

Workload identity: Cryptographically represented identity of a deployed software workload.

Review Questions

Short Answer Questions

1. Distinguish a digital identity, an account, and a credential.
2. Why is suspension not a required step before deprovisioning?
3. What is the purpose of lifecycle reconciliation?
4. How does device proofing differ from workforce identity proofing?
5. Why should recovery be treated as another form of identity proofing?

Long Answer Questions

1. Explain the complete identity lifecycle and the events that can cause transitions between states.
2. Compare lifecycle controls for workforce, customer, partner, service, and device identities.
3. Describe a secure credential process from generation and binding through rotation and revocation.
4. Explain the major components of an enterprise IAM architecture and their relationships.
5. Discuss the privacy, accessibility, and accountability issues associated with identity proofing and automated risk decisions.

Analytical / Application Questions

1. A company disables terminated workers in its central identity provider but leaves cloud API keys and application sessions active. Analyze the control failure and design a complete deprovisioning workflow.
2. Design an identity lifecycle for an Internet of Things deployment containing 50,000 intermittently connected devices. Address enrollment, certificate rotation, quarantine, offline revocation limitations, and audit evidence.
3. An audit finds 36 orphan accounts among 2,400 active accounts. Calculate the orphan-account rate, interpret what the result establishes, and explain what it cannot establish about security risk.

Multiple Choice Questions with Answers

Question 1

Which statement correctly describes a normal workforce termination?

A. The identity must always be suspended before deprovisioning.

B. The active identity may transition directly to deprovisioned status.

C. Only the password must be deleted.

D. The identity must first enter credential recovery.

Correct Answer: B. The active identity may transition directly to deprovisioned status.

Question 2

Which system is normally the authoritative source for a managed device's organizational status?

A. A customer marketing database

B. A password manager

C. An asset inventory or device-management platform

D. A web session cache

Correct Answer: C. An asset inventory or device-management platform

Question 3

What is the primary purpose of credential binding?

A. To associate a credential with the correctly verified identity

B. To copy one credential to every target system

C. To convert an entitlement into an audit record

D. To extend every credential indefinitely

Correct Answer: A. To associate a credential with the correctly verified identity

Question 4

Which sequence best represents safe automated credential rotation?

A. Revoke the old credential, delete the identity, and then create a new account

B. Create and test a new credential, transition dependents, then revoke the old credential

C. Keep both credentials valid permanently

D. Send the old private key to every dependent service

Correct Answer: B. Create and test a new credential, transition dependents, then revoke the old credential

Question 5

Why should event-driven lifecycle automation be supplemented by reconciliation?

A. Reconciliation makes authoritative sources unnecessary.

B. Reconciliation guarantees that no user needs authentication.

C. Reconciliation detects differences caused by missed events or failed target updates.

D. Reconciliation replaces audit logging.

Correct Answer: C. Reconciliation detects differences caused by missed events or failed target updates.

Question 6

Which recovery method is most appropriate for a service identity?

A. Answering personal knowledge questions

B. Calling the employee help desk as a human user

C. Redeploying or re-attesting the workload through an approved platform

D. Sending its existing secret through email

Correct Answer: C. Redeploying or re-attesting the workload through an approved platform

Question 7

An organization finds 18 orphan accounts among 1,200 active accounts. What is the orphan-account rate?

A. 0.15%

B. 1.5%

C. 6.7%

D. 15%

Correct Answer: B. 1.5%

Question 8

Where should evidence of lifecycle actions normally flow?

A. From operational lifecycle systems into a protected audit repository

B. From the audit repository into the authoritative HR system as original evidence

C. From customers directly into certificate revocation lists

D. From policy enforcement points into credential private keys

Correct Answer: A. From operational lifecycle systems into a protected audit repository

Question 9

Which action is necessary for complete deprovisioning but is not achieved merely by disabling an account?

A. Changing the user's display name

B. Revoking active sessions and associated credentials

C. Increasing the session lifetime

D. Preserving all existing entitlements

Correct Answer: B. Revoking active sessions and associated credentials

Question 10

Which statement about OAuth 2.0 is correct?

A. It is principally an authorization framework.

B. It is an asset inventory protocol.

C. It is a certificate revocation list format.

D. It is a human-resources proofing standard.

Correct Answer: A. It is principally an authorization framework.