Lifecycle Management

The Principle

Adding a person is adding their definition. Removing them is deleting it. In both cases, automation provisions or revokes their access across all managed systems. Simultaneously, correctly, and without delay.

The Day-One Experience

In many organizations, a new hire's first days are defined by waiting. Waiting for credentials. Waiting for access to the code repository. Waiting for someone to add them to the right channels. Waiting for a ticket to be processed so they can reach the staging environment. Each system is provisioned independently, at different speeds, by different people.

In the declarative model, a new hire's access is defined before their first day. On their start date, a single change is applied and all systems are provisioned. They arrive and everything works. This is not a minor quality-of-life improvement. It changes how an organization welcomes new members and how quickly they can contribute.

Contractors experience a worse version of this. Their onboarding is often rushed because their start date is driven by a project timeline, not an HR calendar. The systems they need may differ from what full-time engineers require, but the provisioning process does not distinguish between the two. A contractor who needs read access to a single repository and a VPN connection may instead receive the default engineering role because creating a scoped-down contractor role is too much work for a three-month engagement. The over-provisioning is rationalized as temporary. It rarely is.

Verifiable Revocation

Incomplete offboarding is among the more common and more dangerous failures in identity management. A former employee with lingering access to production systems, customer data, or internal communications is a security incident waiting to happen.

In the declarative model, offboarding is complete for all access that the system manages. If fan-out provisioned access across thirty systems on day one, the deletion revokes access across those thirty systems on the last day. There is no managed system that gets missed because no one knew about it. The revocation is complete within the system's boundaries.

This qualifier matters. The declarative system manages all provisioned access. It does not manage all access in the abstract. A person who installed a CLI token on their personal laptop has escaped the model. So has someone who saved a service account credential outside the organization's password manager. So has someone who generated SSH keys independently of the provisioning system. Organizations still need credential rotation, device management, and session revocation as complementary controls.

After a person is removed, the system confirms that access has been revoked in each downstream system. Any failure to revoke is flagged immediately, not discovered during a quarterly audit months later. This answers the question that security teams face: “Can you prove that this former employee has no provisioned access?” In the declarative model, the answer is yes: the deletion is recorded, the revocation is confirmed, and the verification is documented.

Contractors and third parties amplify this risk. They sit outside the HR system that normally triggers offboarding. Their engagement ends in a contract, not a termination event. The procurement system may record that the contract has ended, but if that signal does not reach the access system, revocation depends on the same manual process that provisioned the access. Each external identity is a gap in the lifecycle model.

The Bad Leaver

Consider the scenario that security teams dread: an employee is terminated for cause and must be offboarded immediately. Not at the end of the week. Not after a handover period. Now.

In the traditional model, this is a fire drill. The security team must first answer a question that should be simple but isn't: what does this person have access to? Often the answer is incomplete. Access was granted over years, across dozens of systems, by different administrators, through different processes. Some of it was provisioned by IT. Some was requested through a manager. Some was granted ad-hoc during an incident three years ago and left in place. The team begins searching: checking the identity provider, scanning cloud consoles, querying each SaaS application one by one. Each system they check takes time. Each system they miss is a gap.

Hours pass. The person's VPN is disconnected, but they still have a cloud CLI token that works. Their email is suspended, but they can still push to a repository through an SSH key. Each discovery triggers another revocation, another wait, another verification. The process is sequential, manual, and uncertain. No one can confidently say “we're done.”

In the declarative model, the question “what does this person have access to?” is already answered for all managed systems: by the configuration itself. The answer is not scattered across thirty admin consoles; it is in one file, in one repository, readable in seconds. Offboarding is not a search followed by a sequence of revocations. It is a single deletion followed by automated, parallel revocation across all managed systems, with verification that each one succeeded.

This power scales with coverage. An organization that has integrated twenty of thirty systems can revoke access to twenty systems in seconds and knows exactly which ten remain manual. That is still better than searching through all thirty with no map.

The speed difference is not incremental. It is categorical. One model requires investigation before action. The other requires only action for the managed surface, with a clear list of what falls outside it.

Graceful Transitions

Offboarding is not always instantaneous. A departing employee may need a transition period: email forwarding, file handover, knowledge transfer. The declarative model supports staged offboarding: immediate access revocation to sensitive systems, deferred handling of data and communications: all defined in the configuration, all executed by automation, all auditable.

Consistency Across Cohorts

The twentieth engineer onboarded this quarter gets the same access as the first. There is no variation between administrators, no drift between onboarding guides, no “oh, we forgot to add them to that system.” The configuration is the onboarding checklist, and automation is the administrator. The process is as reliable on the hundredth execution as on the first.

Acquired employees represent a different kind of cohort: a group that was onboarded under a completely different set of assumptions. Their access reflects the acquired company's conventions, not the parent organization's. Bringing them into the model is not a single provisioning event but a migration: the old access is documented, expressed in the declarative configuration, and then progressively reconciled against the unified role model. The result is that the acquired cohort converges toward the same consistency as everyone else, but the process is measured in reconciliation cycles, not in a single cutover.

Antipatterns

• Onboarding requires more than one ticket because each system is provisioned separately.
• No one can say what access a departed employee actually had.
• Offboarding takes days or weeks, or is never truly completed, because access must be discovered before it can be revoked.
• The twentieth hire gets different access than the first.
• Contractor access is not tied to the engagement lifecycle and persists after the contract ends.
• Acquired employees retain their original access patterns with no plan to align them to the unified model.