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.

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. 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. The declarative system manages all provisioned access. It does not manage all access in the abstract. 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.

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: 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.

The speed difference is not incremental. It is categorical. One model requires investigation before action. The other requires only action, because the investigation was done in advance: it is the configuration.

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.

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.