Identity and access management for employees and contractors, commonly integrated with employer-controlled onboarding, offboarding, devices, and security policy.

A trust arrangement in which one organization accepts authentication assertions from another organization's identity provider.

Delegated administration

Limited authority granted to an administrator to manage identities or access within a defined boundary, such as one partner organization.

Customer identity and access management: self-service identity capabilities designed around customer experience, privacy, consent, scale, and fraud resistance.

Collecting and validating evidence to establish confidence that a person is the claimed real-world identity. It is different from merely verifying control of an email address.

Customer identity and access management, focused on consumer or client-user registration, authentication, privacy, consent, recovery, and fraud.

Proof Key for Code Exchange, an OAuth protection that helps prevent authorization-code interception and injection attacks.

SPIFFE Verifiable Identity Document, a cryptographically verifiable workload identity document that can be represented as an X.509 certificate or JWT.

A trust model in which an application accepts identity assertions from an external identity provider.

One Enterprise, Four Identity Populations — Enterprise IAM and Zero Trust Architecture

1. Start With the Population, Not the Login Screen

Same service, different identity problem

Employees, partners, customers, and workloads may call the same API, yet they differ in trust, lifecycle, privacy, scale, and user expectations.

A design sequence

First identify the actor and its relationship to the enterprise. Then assess harm from misuse. Only then choose authentication, lifecycle, recovery, and controls.

Avoid the copy-and-paste trap

Corporate-directory assumptions can frustrate customers, centralize partner administration, and leave workloads dependent on long-lived secrets.

2. Compare the Four Populations

Five comparison questions

Compare assurance, lifecycle ownership, privacy, scale, and user experience. Authentication technology alone cannot answer these design questions.

Human populations differ

Employees are usually enterprise-managed. Partners are organization-managed. Customers are self-service users with stronger usability and privacy expectations.

Workloads are not users

A workload needs runtime attestation, narrowly scoped machine permissions, credential rotation, and observability rather than enrollment screens.

3. Example: A Shared Procurement Platform

Employees

The analyst uses enterprise sign-in, workforce groups, device and risk signals, and step-up authentication for high-value approvals.

Partners and customers

A supplier federates from its own organization. A customer self-registers with low friction, privacy choices, and stronger checks for sensitive changes.

Workloads

The inventory service receives a runtime credential with narrow API permissions. It does not share a human account or store a permanent API key.

4. Design Triage: Which Assumption Fails?

Thought exercise

Your organization proposes one rule for every population:

"Every identity must be manually created by the central IT service desk, use a corporate password policy, and request access through the employee manager workflow."

For each population, identify the failure:

Customer: What happens to sign-up conversion and account recovery?
Partner: Who actually knows whether a supplier employee should retain access?
Workload: What would "password reset" mean for a container that starts and stops automatically?
Employee: Which part of this rule may still be useful, and why?

5. Partner Access: Federation Plus Delegation

Federate authentication

A partner can authenticate its own employees through its identity provider. Your service still validates assertions and controls what each person can do.

Bind identity to an organization

Map each federated user to the correct partner tenant. Then apply organization-scoped roles, attributes, and resource boundaries.

Delegate safely

Partner administrators may manage their own users, but cannot administer other organizations, alter global policy, or create enterprise-wide privilege.

6. Customer IAM: Registration, Recovery, Consent, and Fraud

Make registration proportionate

Use a low-friction registration path, collect only necessary data, and add bot and abuse defenses. Verification of a channel is not proof of a person.

Protect recovery

Recovery can become an account-takeover path. Use risk-based evidence, notifications, audit logs, and extra safeguards for sensitive changes.

Consent is not a checkbox

Record optional consent by purpose and version. Make withdrawal manageable, and do not confuse essential terms with optional data processing.

7. Workload Identity: Replace the Shared Secret

From static API keys to runtime identity

A long-lived API key stored in source code, a configuration file, or a CI/CD variable is difficult to rotate and easy to reuse after exposure. Prefer a managed workload identity when the platform and architecture support it.

Migration sequence

Inventory every workload, API key, service account, and secret owner.
Define a distinct workload identity, such as `payments-api` or `inventory-sync`.
Attest the workload from runtime evidence such as cloud workload identity, Kubernetes service account, or another trusted platform signal.
Issue a short-lived token or certificate.
Give the workload only the audience, scope, and resource permissions it needs.
Validate identity and authorization at the receiving service.
Monitor usage, rotate automatically, and retire the old static secret.

Never use a human account as a service identity. Human and workload lifecycles, accountability, and credential handling are different.

SPIFFE is one standards-based approach: a workload can obtain a cryptographically verifiable identity document, called an SVID, through the SPIFFE Workload API. X.509-SVIDs and JWT-SVIDs are supported; SPIFFE guidance advises X.509-SVIDs where possible because bearer-style tokens can be replayed if stolen.

8. Architecture Challenge: Choose the Right Control

Match each scenario to a control

Choose the most appropriate primary control for each situation.

A supplier wants to manage which of its employees can see its invoices.
A consumer wants to delete a marketing preference but keep using the product.
A Kubernetes job needs to call an internal API for ten minutes.
An employee is promoted to a finance approver role.

Suggested mapping

Federation plus delegated administration within the supplier organization boundary.
Purpose-specific consent management and preference withdrawal.
Short-lived workload credential issued from runtime identity or platform attestation.
Workforce lifecycle event plus dynamic authorization and, if needed, privileged-access controls for elevated actions.

Notice that the answers combine this module with earlier IAM concepts. Authentication establishes an identity; authorization evaluates whether that identity may perform the requested action in the current context.

9. Knowledge Check

Choose the best answer

A company lets every partner user sign in with an account manually created by the company's help desk. A partner cannot promptly remove a departed employee, and the company cannot reliably tell which partner organization owns each account.

What is the best architectural improvement?

Which change most directly addresses both lifecycle ownership and organization boundaries?

Use a shared password for all users from the same partner
Federate with the partner identity provider, map users to a partner organization, and delegate scoped administration
Give every partner user the same enterprise employee role
Require partners to call the help desk more frequently

Show Answer

Answer: B) Federate with the partner identity provider, map users to a partner organization, and delegate scoped administration

Federation lets the partner manage authentication and employee lifecycle, while organization mapping and scoped delegation preserve the enterprise's authorization and audit boundaries.

10. Review the Core Vocabulary

Flip the cards

Use these terms to explain why one enterprise needs more than one identity pattern.

Workforce IAM: Identity and access management for employees and contractors, commonly integrated with employer-controlled onboarding, offboarding, devices, and security policy.
B2B federation: A trust arrangement in which one organization accepts authentication assertions from another organization's identity provider.
Delegated administration: Limited authority granted to an administrator to manage identities or access within a defined boundary, such as one partner organization.
CIAM: Customer identity and access management: self-service identity capabilities designed around customer experience, privacy, consent, scale, and fraud resistance.
Identity proofing: Collecting and validating evidence to establish confidence that a person is the claimed real-world identity. It is different from merely verifying control of an email address.
Workload identity: A verifiable identity for software such as a service, container, function, or virtual machine, used to authenticate machine-to-machine access.
Short-lived credential: A token or certificate that expires quickly and is renewed automatically, reducing the value of a stolen credential compared with a permanent secret.
Consent record: Auditable evidence of a person's choice for a specific data-processing purpose, including the purpose, policy version, time, and collection method.

Key Terms

CIAM: Customer identity and access management, focused on consumer or client-user registration, authentication, privacy, consent, recovery, and fraud.
PKCE: Proof Key for Code Exchange, an OAuth protection that helps prevent authorization-code interception and injection attacks.
SVID: SPIFFE Verifiable Identity Document, a cryptographically verifiable workload identity document that can be represented as an X.509 certificate or JWT.
federation: A trust model in which an application accepts identity assertions from an external identity provider.
authorization: The process of deciding whether an authenticated actor may perform a requested action on a resource.
authentication: The process of verifying that an actor controls an identity or authenticator.
least_privilege: Granting only the minimum permissions needed to perform an authorized task.
identity_proofing: Establishing confidence that a person is the real-world individual they claim to be.
workload_identity: A machine identity used by software processes to authenticate and authorize service-to-service actions.
identity_assurance: The degree of confidence that an identity claim and its authentication are reliable enough for a particular risk level.
step_up_authentication: Requesting stronger authentication when an action or risk signal requires greater confidence.
delegated_administration: Granting constrained administrative authority within a defined scope, such as one customer or partner tenant.

One Enterprise, Four Identity Populations