IBMid Policies

DormantIDs: IBMid policy for deletion of dormant IBMid IDs

• Background:
  • Abandoned IDs are more vulnerable to malicious threats, including account hijacking.
  • It is a best practice that “stale” accounts are removed or disabled after being inactive for a defined amount of time.

• Policy:
  • IBMid IDs are considered “dormant” after 36 months of inactivity, where “activity” is a login, defined as follows:
    • An interactive login to any IBMid-enabled application, via means of authentication by ID/password/MFA or Enterprise Federation.
    • API key usage tied to an IBMid is not considered to be a login. For example, using a Cloud API key to authenticate an IBMid identity to the Cloud CLI or an API is not recorded as a login to IBMid.
  • Dormant IDs are subject to disablement and deletion.

• Enforcement:
  • Periodically, IBMid will scan identities for dormancy.
  • Once selected as dormant, an ID will be submitted for revocation.
  • A “revoked” ID is initially disabled for login and will be permanently deleted after 30 days.
  • Prior to permanent deletion, a user can request reinstatement via an IBMid support request. If reinstated, the ID will be removed from the deletion queue and re-enabled for login.

IDControl: IBMid policy for control of IDs

• Backgroud:
  • IBMid ID types include:
  • Individual IDs
    • The user manages their own account information.
    • The ID is accessed through the IBMid login service (i.e. IBMid is the authenticating agency).
  • Enterprise IDs
    • An “enterprise” (i.e. company or other organization) manages the user’s account information.
    • The ID is accessed using the enterprise login service, which is enabled with IBMid Enterprise Federation (i.e. the enterprise is the authenticating agency).

• Policy:
  • If an IBMid ID is created using an email address containing a domain owned by an organization (owning organization) which the user is employed by, contracted to, or a volunteer for, the owning organization can:
    • inquire about the status of the ID, including when the ID was last accessed, or other information relevant to the user’s ID activity.
    • request the user’s account settings (including personal information associated with the ID).
    • at its option, convert it to an Enterprise ID.
  • Once converted to an Enterprise ID, an authorized party from the owning organization must approve conversion back to an Individual ID.
  • Enterprise IDs will not have a usable password allowing the user to authenticate directly with IBMid. The user must always authenticate through the enterprise identity provider (IdP).

• Enforcement:
  • IBMid Enterprise Federation will require an authorized party (nominally the IBMid Business Owner) to approve ID conversions from Individual to Enterprise IDs or vice-versa.

Important Policies