Identities, patches, logs, and assets | Security+: security and production decisions

Concept and mechanism

Disabling an account can prevent new login without invalidating every issued session or token. A departure procedure needs an inventory of access mechanisms and revocation validation across relevant systems. For batch and services, prefer dedicated identities with limited privileges rather than dependence on an administrator’s personal password. Define owner, consumers, and rotation mechanism. Control should support continuity without informal account sharing and retain enough evidence to attribute changes and investigate misuse.

Guided application

A patch marked installed does not prove the process stopped using vulnerable code. Confirm effective version, restart requirements, and validation results on the correct asset. To observe these operations, use logs with correlation IDs, context, and suitable retention while avoiding full passwords and tokens. A team reading logs should not automatically receive reusable credentials. At hardware end of life, deleting filenames does not prove sanitization. Select a process appropriate to media and sensitivity, retain identity and completion evidence, and coordinate inventory removal with applicable retention requirements.

IN PRACTICE

At service handover, provide workload identity, rotation procedure, and evidence of an active patch. Retain request ID in logs while removing the access token.

Common pitfalls

Confusing account and session; using personal service credentials; closing findings from installation alone; logging secrets; accepting deletion as sanitization.

Related topics: Incidents and controlled response · Governance, risk, and suppliers

Take this idea with you

Evidence should demonstrate real state after change and at end of life.

Create account

Reference: Enterprise patch management planning · SY0-701 V7