[Openid-specs-ipsie] IL1 => deprovisioning is 80% of the value

[Shannon Day]

Changing an identity lifecycle stage like IL1 or AL1 to focus solely on
deprovisioning is a strategic move that aligns with modern security
priorities. While the specific terms (IL1, AL1) likely refer to an internal
framework, the core concept of prioritizing automated offboarding reflects
a critical trend in identity management.
The premise that deprovisioning constitutes 80% of directory sync's value,
while not a universal, citable metric from "Karl and ChatGPT," holds
significant weight in cybersecurity discussions. Inadequate deprovisioning
is a major security risk that can lead to data breaches, compliance
violations, and unnecessary license costs.
Here is an analysis of the pros, cons, and implications of this approach.
Pros of prioritizing deprovisioning

   - Enhanced security posture: Prompt and automated deprovisioning
   immediately revokes access for departing employees, contractors, or users
   whose roles have changed. This eliminates the risk of "orphan" or "zombie"
   accounts that are often exploited by malicious actors.
   - Reduced compliance risk: Many regulations, such as GDPR and HIPAA,
   mandate timely removal of access to sensitive data. An automated
   deprovisioning process provides a verifiable audit trail, helping to prove
   compliance and avoid steep penalties.
   - Financial savings: By immediately removing user accounts and access
   from licensed applications, organizations can stop paying for unused
   software licenses and other resources, leading to significant cost savings.
   - Elimination of human error: Manual offboarding is prone to human
   error, including forgetting to disable accounts in certain applications.
   Automating this critical step ensures consistency and completeness every
   time.
   - Improved operational efficiency: An automated process frees up IT and
   security staff from tedious, time-consuming offboarding tasks. It allows
   them to focus on more strategic initiatives.

Cons and considerations for implementation

   - Diminished focus on provisioning and access management: If the initial
   lifecycle stage is entirely dedicated to offboarding, it could de-emphasize
   the importance of robust, policy-driven provisioning and role-based access
   control (RBAC). A comprehensive identity lifecycle management (ILM)
   solution needs to handle the full user journey, including joiner and mover
   events.
   - Business continuity challenges: While immediate deprovisioning is good
   for security, it can create problems for business operations. For example,
   access may be revoked before a departing employee's files or email can be
   transferred. The process must account for the transfer of data and
   knowledge to another employee.
   - Temporary access needs: Some scenarios, like a suspension or leave of
   absence, require temporary access revocation rather than full
   deprovisioning. A simple, binary deprovisioning stage would not
   differentiate between these nuanced events.
   - Lack of identity proofing: Traditional identity lifecycle models often
   start with a stage focused on identity proofing (such as NIST's IAL1-3
   framework). If the first stage is deprovisioning, it assumes the identity
   has already been securely proven, which might not be a valid assumption.
   - Internal terminology confusion: Re-labeling or redefining an existing
   lifecycle stage like IL1/AL1 could cause confusion for employees familiar
   with the previous framework. This could require significant change
   management to communicate the new purpose.

Recommendations and best practices
Instead of replacing IL1/AL1 entirely with deprovisioning, a more
comprehensive approach would be to:

   1. Introduce a specific, high-priority offboarding stage: Create a
   dedicated lifecycle state for terminated users that automatically triggers
   immediate deprovisioning actions across all systems. This can run in
   parallel with other lifecycle stages.
   2. Use event-driven triggers: Base lifecycle actions on events from the
   source-of-truth HR system (e.g., "termination date" or "employee status =
   inactive"). This ensures deprovisioning happens automatically, in
   real-time, based on reliable data.
   3. Implement multi-stage deprovisioning: For complex environments, a
   multi-stage process might be best. The first stage can immediately revoke
   high-privilege access, while subsequent stages can handle data archiving
   and account deletion after a waiting period.
   4. Integrate with a robust IAM/IGA platform: Leverage a platform that
   offers automated workflow capabilities. This is the most effective way to
   manage the complexity of user lifecycles, from provisioning to
   deprovisioning, in a consistent and automated way.


Shannon Day

On Tue, Sep 16, 2025, 12:29 PM Dick Hardt via Openid-specs-ipsie <
openid-specs-ipsie at lists.openid.net> wrote:

> https://github.com/openid/ipsie/pull/113
>
> On Tue, Sep 16, 2025 at 4:14 PM Dick Hardt <dick.hardt at gmail.com> wrote:
>
>> Quoting both Karl and ChatGPT, 80% of the value in directory sync is
>> deprovisioning.
>>
>> What does everyone think of changing IL1 (or AL1 if we move to account
>> lifecycle) to be deprovisioning?
>>
>> I'm proposing that we describe that the users may have been provisioned
>> via JIT or manually, and provisioning is out of scope for IL1.
>>
>> In IL1, the identity service MUST do account resolution to link the app
>> identifiers with the identity service identifiers, and then the app must
>> deprovision an account when directed by the identity service.
>>
>> An app delegating provisioning to the identity service would be included
>> in IL2 and would include profile and group membership.
>>
>> Hopefully we will have some time to discuss today
>>
>> /Dick
>>
> --
> Openid-specs-ipsie mailing list
> Openid-specs-ipsie at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ipsie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ipsie/attachments/20250916/cea6472f/attachment.htm>