What Safeguard 5.3 asks for when accounts sit unused
Safeguard 5.3 asks the organization to delete or disable dormant accounts after 45 days of inactivity, where the platform supports it. It sits in the Users asset class under the Protect security function and is assigned to all three Implementation Groups, which makes it part of IG1 essential cyber hygiene. If you are working through an inactive-account backlog against CIS Controls v8.1, treat this Safeguard as a baseline you must meet in every environment, not an advanced target. The first decision is who owns the 45-day rule: the organization sets the inactivity policy and its exceptions, and the technical team applies it consistently across directories, SaaS applications and cloud consoles.
The risk is simple. An account nobody uses still holds a valid credential, and an attacker who obtains that credential gets a foothold that no one is watching. Old contractor accounts, departed employees whose access was never removed and test accounts left behind after a project are common examples. The difficulty is that last-login data is scattered. Directory services record logons differently from SaaS applications, cloud identity providers may not expose a last-used timestamp for every role, and service accounts often have no interactive login at all. Before you can count dormant accounts, you need the account inventory described in Safeguard 5.1, because the assessment specification treats that inventory as a prerequisite for measuring this Safeguard.
Start by confirming, for each system in scope, whether it exposes a last-login or last-activity field and how reliable that field is. Where a system does not support automatic disablement, record that limitation and the compensating process, such as a scheduled manual review. Then ask your identity team which system is authoritative for each account lifecycle, so that a disable action in the directory reaches downstream applications. An identity platform that provisions and deprovisions users to target applications, such as the SCIM provider in authentik documentation, can remove the manual step, but you must still verify that the target application honors the deprovisioning request and that the dormant-account report reflects the result.
Which accounts and systems fall under the 45-day rule
Safeguard 5.3 applies to every account the enterprise manages, not only the ones in the directory. The cards below separate the account types an assessor expects you to count, the places where "where supported" changes the work, and the accounts held by people or providers outside your direct control.
Human user accounts
These are employee, contractor and partner accounts that sign in to workstations, applications and networks. Start with the accounts in your central directory, then confirm that HR-driven joiner, mover and leaver processes actually disable them. Check whether an account that was never used after onboarding still counts as dormant, because the 45-day clock is about inactivity, not age.
Service accounts
Service accounts run scheduled jobs, integrations and batch processes, and they often show no interactive logins. Their inactivity can look like dormancy even when a process still depends on them. Use the account inventory from Safeguard 5.1 and the service account inventory from Safeguard 5.5 to confirm an owner and purpose before you disable anything, and record the exceptions you accept.
Cloud and SaaS application accounts
Accounts in cloud consoles and SaaS tools frequently exist outside the central directory, created by a team for a single project. Identify which of these applications read identities from your directory and which keep local user tables. For local tables, the 45-day check must run inside each application, and an assessor will expect you to show the last-login data for each one.
Local accounts on endpoints
Local accounts on laptops, servers and appliances are often missed because they never touch the directory. Many of them are break-glass or vendor accounts that should exist but stay unused for long periods. Decide which local accounts are excluded by design, document that decision, and confirm that the remaining local accounts are inside the scope of your dormancy review.
Where "where supported" changes the work
The Safeguard applies the 45-day rule only where the system supports disabling or deleting dormant accounts or reporting their last activity. Where a platform cannot do this, the work moves to a documented compensating process, such as a scheduled report reviewed by a named owner. Ask each platform owner to confirm in writing whether the capability exists, because an assessor will test the process you document, not the one you intended.
Accounts held by third parties
Managed service providers, contractors and software vendors may hold administrative or application accounts that your teams do not create or see. Your contracts and service provider management process should require these providers to report dormant accounts or disable them on request. Confirm which provider accounts can reach your systems, and treat any gap in visibility as a finding you must record and close.
How assessors count dormant accounts that are still enabled
An assessor using the CIS Controls Assessment Specification (CAS) for v8.1 does not start with the dormant accounts themselves. The starting point is the account inventory from Safeguard 5.1, because the specification lists that inventory as a prerequisite for measuring Safeguard 5.3. Without a complete list of user, administrator and service accounts across directories, applications and cloud tenants, an assessor cannot show that the dormant population is complete. Before the test begins, confirm that the inventory includes the fields needed to evaluate each account, especially last-activity data, account status and owner. Gaps in the inventory usually surface as accounts that were never counted, which is the most common reason a dormant account finding is later reopened.
CAS defines six measures for Safeguard 5.3, and these combine into two metrics: dormant accounts and enabled dormant accounts. The first metric counts accounts whose last recorded activity is older than the 45-day threshold. The second counts the subset of those accounts that remain enabled and could still authenticate. Applying the threshold depends on the quality of last-activity data. Assessors will ask where that timestamp comes from, whether it is updated by successful logins only or by every authentication attempt, and whether it is available for every system in scope. If one application does not record last use, the organization should say so openly and record how those accounts are handled, rather than letting them silently fall outside the count.
How an assessor tests Safeguard 5.3
This table walks through how an assessor typically tests Safeguard 5.3, step by step, with the evidence requested and the findings that come up most often. Read it as a checklist of what to prepare before an assessment, since each row maps to a measure the assessment specification uses to count dormant and enabled dormant accounts.
| Test step | What the assessor looks for | Common findings |
|---|---|---|
| Account population extraction | A complete export of user accounts from each directory, identity provider and application that holds local accounts, with account status and last-activity fields | Exports cover the directory but miss local or application accounts, so dormant accounts outside the directory are never counted |
| Last-activity check against the 45-day threshold | Last sign-in or last-activity timestamps compared against the 45-day inactivity threshold, with the date of the extract recorded | Last-login fields are blank or never populated for some platforms, so inactivity cannot be shown |
| Disable or delete confirmation | Evidence that accounts past the threshold were disabled or deleted, such as status changes, deletion logs or automated job records | Automation runs but no record of its results is kept, or accounts are disabled without a ticket or audit entry |
| Exceptions where the platform does not support automated disabling | A documented list of systems without automatic disabling, the manual procedure used instead and proof that the procedure runs | Exception lists are missing, out of date, or hold accounts that no owner has reviewed for months |
| Sampling of recently disabled accounts | Selected accounts that were disabled or deleted recently, traced back to the inactivity report and the disable event | Disabled accounts still hold active group memberships or licenses, or re-enabled accounts are not traced to an approved request |
| Enabled dormant accounts count | The number of accounts that are both past the threshold and still enabled at the time of the extract, which assessors treat as the key failing condition | Accounts past the threshold remain enabled because the job skips service or shared accounts without a stated reason |
Implementing the 45-day dormant account process
The sequence turns Safeguard 5.3 from a policy sentence into a repeatable process: an inventory that covers every account, last-activity data for each system, a written disable-or-delete rule with a named owner, automation where identity providers support it, and a recurring review that produces evidence an assessor can re-perform.
Confirm the account inventory from Safeguard 5.1
Start from the account inventory required by Safeguard 5.1, which the CIS Controls Assessment Specification treats as a prerequisite for measuring Safeguard 5.3. Confirm it lists user, administrator and service accounts for every system in scope, with an owner or status field for each. Done means every enabled account in each in-scope system appears in the inventory, and any gaps are logged as open items with a named person responsible for closing them.
Capture last-login fields for each system
For each system in the inventory, record where the last successful sign-in or activity timestamp lives, such as the directory's last logon attribute, an application's user table or the identity provider's event log. Pull that field into the inventory so every account has a last-activity value. Done means each in-scope system has a documented source for last activity, and the team can show a sample extract for at least one account per system.
Define the disable-or-delete rule and its owner
Write the rule that applies once an account passes 45 days of inactivity: disable it, delete it, or follow a defined sequence for each account type. Name the owner who approves exceptions, such as accounts used by a vendor or a seasonal role, and record how exceptions are approved and reviewed. Done means a signed or approved standard exists that states the 45-day threshold, the action, the owner and the exception path.
Automate disablement where the identity provider supports it
Where a central directory or identity provider governs access, configure the process to disable or remove accounts from there and let provisioning flow to connected applications. Tools such as the authentik SCIM provider, which pushes user changes and deprovisions users from target applications, or FreeIPA, which centralizes users and groups in 389 Directory Server, can reduce manual steps. Confirm each product's current capabilities against its documentation before relying on them. Done means a test account that is inactive past the threshold is disabled in the central source and the change reaches at least one connected application.
Handle platforms without last-activity data
Some applications, appliances and local accounts do not record last activity. For these, decide an interim method: export the account list on a schedule and compare it with sign-in logs where they exist, route access through a central identity service that does record activity, or document the platform as a compensating gap with a target date set by the owner. Do not assume an account is active because no data exists. Done means every platform without last-activity data has a recorded method or documented gap, and the owner has accepted it in writing.
Run the dormancy check and act on results
Run the check against the consolidated inventory, identify accounts past the threshold, and apply the disable-or-delete rule. Keep the query, its run date, the list of accounts found and the action taken for each. The assessment measures count dormant accounts and enabled dormant accounts, so the output should show both figures before and after action. Done means the report lists every dormant account, its action and the approver, and the enabled-dormant count is zero or each remaining case has an approved exception.
Set a recurring review and retain the evidence
Schedule the dormancy check to repeat on a fixed cadence set by the organization, and assign an owner to review the output and sign off. Store each run's query, results and approvals so the sequence can be re-performed. Also review the exception list at each cycle so approvals do not persist without reason. Done means at least two consecutive review cycles exist with dated outputs, sign-offs and exception reviews an independent assessor can sample.
Automating dormant account detection by platform
When accounts sit in a central directory such as FreeIPA, the directory is the natural place to find inactive users and to disable them. FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects, with centralized access control and delegated administration through its web UI and command line tools. Because every login to a directory-bound system passes through that store, the directory can answer which accounts have not authenticated within the window and whether they are still enabled.
- Login timestamps: Confirm which last-login attributes the directory records for each account type and whether they update for every service that binds to it.
- Coverage gaps: Accounts that never touch the directory, such as local application accounts, will not appear in a directory report.
- Disable versus delete: Check whether disabling a user blocks all bound services or only some of them.
- Scheduled reporting: Retain the query, its output and the date it ran as evidence of the 45-day review.
Confirm these points with your FreeIPA version and your own integrations before you rely on the directory as the single source of truth.
An identity provider such as authentik sits in front of applications and can push account changes to them. The authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users from the target when they lose access to the application. This makes the identity provider a strong place to enforce disablement, but it proves only what the provider knows and sends.
- Deprovisioning events: Check that removal of a user from the provider reaches each target application, and keep logs of those sync results.
- Last activity: Confirm whether the provider records last login for each user, which is separate from whether the target application has done so.
- Target gaps: An application that does not support SCIM, or that stores its own local accounts, falls outside the sync.
- Sync failures: Monitor failed syncs, because a stalled sync leaves enabled accounts behind in the target.
Confirm the exact sync behavior, supported target applications and log retention with the authentik documentation for your release.
Some applications keep their own user lists and do not report when each account last signed in. Here the organization has to build the dormancy signal from outside the application, or accept that the application is a manual control. An assessor will still count any enabled account that has been inactive past the threshold, so the gap has to be visible in the inventory from Safeguard 5.1 and handled explicitly.
- Export the user list: Use the application's administrative export or API, if one exists, to compare accounts against the inventory.
- Use external logs: Authentication logs from a proxy, single sign-on or the host can show last use when the application itself cannot.
- Document manual reviews: Where no signal exists, record a periodic review with the reviewer, date, accounts checked and disablement actions.
- Flag unknowns: Accounts with no recoverable activity data should be listed as exceptions with a remediation owner.
- Service and shared accounts: Check that these are not excluded from the review simply because they are not used interactively.
Confirm which signals each application exposes, and whether it supports disabling an account without deleting its records.
Evidence that shows dormant accounts are handled
An assessor testing Safeguard 5.3 looks for proof that inactivity is measured, that accounts beyond 45 days are disabled or deleted, and that exceptions are approved and reviewed. The artifacts below connect those steps, and each one goes stale quickly unless someone refreshes it on a schedule.
Dated account inventory exports
Export the account inventory with a last-activity field for every user account in each directory, identity provider and application that holds local accounts. The assessor uses the export to count dormant accounts, so the timestamp and the source system must appear on the file. Keep the export tied to the Safeguard 5.1 inventory so that every account in one list appears in the other. Between audits, schedule the export monthly and store each run in an immutable location. Confirm that the last-login field comes from the authoritative source and not from a cached copy.
Disable and deletion logs
Logs of disable and delete actions show that the 45-day rule was applied to the accounts it was meant to catch. Each entry should record the account, the action, the time, the rule or person that triggered it, and the last-activity date that justified it. Pull these logs from the directory or identity platform, not from a spreadsheet maintained by hand. Check that the logs cover automated and manual actions, and that log retention is long enough to span the audit period. Review a sample of entries against the inventory export to confirm they match.
Exception register with approvals
Some accounts legitimately stay idle, such as break-glass, seasonal or certain service accounts, and each one needs a written justification. The register should list the account, the owner, the business reason, the approver, the approval date and the next review date. An exception without an approver or an expiry date is a finding waiting to happen. Between audits, reconcile the register against the latest inventory export each quarter so that retired exceptions are removed and new idle accounts are added.
Automated rule configuration
Assessors want to see the configuration that performs the disabling, not just the result. Capture the policy or scheduled job that sets the 45-day threshold, the scope it applies to, and the action it takes, such as disabling rather than deleting. Where a platform supports it, the provisioning connector should also remove access in downstream applications when a user is deprovisioned. Store the configuration in version control so that every change has an author, a date and a reason. Confirm that the threshold in the configuration matches the value in the written policy.
Recurring review records
A dated review record shows that someone checked the outcome of the dormant-account process on a regular cycle and acted on what they found. Each record should list the inventory run reviewed, the number of dormant and enabled dormant accounts found, the actions taken, the reviewer and any open items. Assessors also look for evidence that open items were closed. Keep these records in the same repository as the exports so the chain from finding to action is easy to follow. Ask the auditor which review frequency they expect for your environment before you set one.
Access certification decisions
Where an identity governance tool runs periodic access certifications, its campaign results give a second check on whether idle accounts keep their access. Reviewers decide within a set timeframe whether to keep, change or revoke each access item. Record the campaign scope, the reviewer assignments, the decisions and the revocations. Confirm with your tool vendor how campaign results are exported, since the export is the artifact an assessor will ask to see.
What meeting Safeguard 5.3 costs in money and effort
This table separates the cost components of meeting Safeguard 5.3, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Read it to decide where your budget goes and what to request in a quote, since open-source tooling removes license spend but not integration or evidence work.
| Cost component | Who is paid or who does the work | One-time or recurring, and main drivers |
|---|---|---|
| Tooling and licenses | Software vendors for commercial directories or identity platforms, if used. Open-source platforms carry no license fee. | Open-source removes license spend but not integration. Commercial licenses recur and scale with user or application counts. |
| Integration and configuration of last-activity data | Internal engineers or an implementation partner connecting each directory and application to a source of last sign-in data. | One-time for the initial build, then recurring for changes. Drivers: number of applications, number of directories and whether each system records last activity at all. |
| Engineering time for last-activity collection | Internal platform or identity engineers, or a contracted partner under a fixed-scope agreement. | One-time to script or configure collection, recurring when systems change. Drivers: systems that do not record last use, which may need a proxy measure you must document. |
| Disable or delete workflow | Internal identity administrators, or automation built during implementation. | Mostly one-time to build, then recurring operations. Drivers: whether disabling is automated, how exceptions are approved and how reactivation requests are handled. |
| Evidence upkeep | Internal compliance or security staff who retain reports, exception records and dated runs of the dormant account check. | Recurring. Drivers: how often the check runs, how many exceptions exist and how long records must be kept under your own policy. |
| Exception review | Account owners and approvers, who justify each account kept beyond 45 days of inactivity. | Recurring. Drivers: number of service and shared accounts that cannot be disabled and how frequently owners must re-approve them. |
| External review | An independent auditor or assessor, if the organization is asked to show results for a framework. The assessor is paid for testing, not for the control itself. | Typically recurring per assessment cycle. Ask the auditor for the sample size and the population they will test before agreeing scope. |
| Auditor sampling and testing | The independent auditor or assessor, who samples accounts and checks last-activity dates against the 45-day threshold. | Recurring per assessment. Drivers: size of the account population, number of directories in scope and how cleanly your reports reconcile to the source systems. |
Open-source tools that support dormant account evidence
Dormant account evidence depends on an identity source that knows who has accounts, when they last signed in and when access should end. The three tools below cover different parts of that chain: automated deprovisioning, the central directory and periodic access review. None of them proves on its own that dormancy is measured, so confirm each capability against your environment and the vendor documentation.
authentik SCIM provisioning
The authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0 and runs a full sync every hour. When a user loses access to an application, authentik deprovisions that user in the target, which removes the enabled account that a dormancy check would otherwise find. Check which target applications support SCIM, and whether your team can show that a disabled account in the target is the result of the sync and not a manual step. The license is MIT, so the tool carries few licensing constraints for internal use.
FreeIPA central directory
FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. Central storage gives you one place to export the account inventory that Safeguard 5.1 requires and to query account status for the dormancy measure. Delegated administration through its web UI and command line tools lets you limit who can disable or delete accounts. Confirm that last login data is recorded for each account type you need to measure, because directory replication does not by itself record activity in every connected application. The license is GPL-3.0-or-later, so review obligations before modifying and distributing the code.
midPoint access certification
midPoint access certification campaigns assign designated reviewers who decide within a set timeframe whether to keep, change or revoke access items such as role assignments. For dormant accounts, a campaign gives you a dated record that a reviewer confirmed or removed access that had gone unused, which supports the review step in your process. Check whether your reviewers can see last activity data for each item, because a review without that data does not show dormancy was assessed. The license is EUPL-1.2 or later, so confirm obligations with counsel if you plan to distribute modified versions.
Measurement against the assessment specification
The CIS Controls Assessment Specification defines six measures for Safeguard 5.3, combined into two metrics: dormant accounts and enabled dormant accounts. Your tools must produce data that lets you count both, including a timestamp for last activity and the account status at the time of the count. Ask each vendor or integrator to show a report that lists dormant accounts and their enabled state, and confirm that the report can be reproduced for an assessor. Do not treat a deprovisioning log alone as proof of the measure.
Who owns the control and who prepares the evidence
Your organization owns Safeguard 5.3. That means it decides the inactivity threshold, accepts the risk of any exception, assigns who reviews dormant accounts and answers for the results. The CIS Controls Assessment Specification measures whether the Safeguard is implemented in your environment, so the work and the accountability stay with the people who run that environment.
- Policy decisions: Set the 45-day inactivity rule in a written account management standard and name the owner who approves exceptions.
- Account inventory: Maintain the account inventory that Safeguard 5.1 requires, since the assessment treats it as a prerequisite for measuring dormant accounts.
- Disablement actions: Decide which accounts are disabled or deleted, and record who performed each action and when.
- Exception handling: Document any account kept active past the threshold, with a business reason, an approver and a review date.
- Ongoing operation: Run the recurring review and keep the records that show it happened.
Confirm that a named role in your organization signs off on the standard and on each exception, because an assessor will ask who made those decisions.
An implementation partner such as DeployOpen can prepare the technical systems and evidence that support Safeguard 5.3 inside your own infrastructure. The partner works on the tooling and the records, while your organization keeps ownership of the decisions and the results. A partner's documentation describes what was configured. It does not state whether the control is effective.
- Identity configuration: Set up self-hosted directory and identity services so that last-login data and account state are available for measurement.
- Automation design: Build deprovisioning workflows, for example through the authentik SCIM provider, so that removed access reaches target applications.
- Evidence preparation: Produce reports of dormant and enabled accounts, along with configuration exports and change logs that an assessor can sample.
- Recurring review support: Configure review campaigns and reminders, where the platform supports them, so the review leaves a record.
- Documentation: Write runbooks that describe how the systems and evidence were built, without claiming the control passed.
Ask the partner to state in writing which deliverables it produces and which decisions remain with your staff.
An independent auditor, assessor or certification body is the only party that issues a conclusion about whether Safeguard 5.3 is met. Independence means the assessor is not the party that built the systems or wrote the evidence it tests. Where your organization uses a CIS Controls assessment, confirm with the assessor which method and scope it will apply, because CIS states that the Controls do not replace any regulatory, compliance or authorization scheme.
- Sampling: The assessor selects accounts from the inventory and checks their last activity dates against the threshold.
- Enabled dormant accounts: The assessor counts dormant accounts that remain enabled, since that count is the figure that shows whether the Safeguard is working.
- Evidence testing: The assessor reviews exports, logs and review records for completeness and for consistency with the live environment.
- Exception review: The assessor examines whether each exception was approved and whether it was reviewed on schedule.
- Reporting: Only the assessor issues the findings, report or attestation.
Before engaging anyone, confirm with the assessor that the partner's involvement is acceptable under its independence rules.
Where organizations usually fall short on dormant accounts
Most organizations can state the 45-day rule in a policy, but the gaps appear when the rule meets real systems. The cards below cover the places where dormant accounts hide from the measurement, from SaaS applications with no last-login data to reviews that stop happening after the first cycle.
No last-login data for SaaS apps
Many SaaS applications record last sign-in only in an admin console, retain it for a short period, or do not expose it at all through their API. Without that signal, no one can show which accounts crossed 45 days of inactivity, and the assessor's dormant count becomes an estimate. Check, for each application, whether last-login is exported, how far back it goes, and whether a scheduled job captures it before it rolls off.
Service accounts excluded from the rule
Teams often exempt service accounts from inactivity checks because automated jobs look idle between runs or because nobody owns them. An unused service account with a live credential is still an enabled account that can authenticate. Confirm that every service account in the inventory from Safeguard 5.1 has a named owner, a recorded purpose and an inactivity rule, and that any exemption is written down with an approver.
Disabled accounts still holding group memberships
Disabling an account stops sign-in but often leaves its group memberships, role bindings and API tokens in place. If the account is later re-enabled, or if a downstream system reads group data without checking the account state, old access returns. Verify that disablement removes or suspends group and role assignments, and that tokens and keys tied to the account are revoked.
Manual reviews that lapse
A spreadsheet review of dormant accounts may be run carefully in the first quarter and then skipped during staff changes or busy periods. An assessor will look for evidence from each cycle, not only the most recent one, so gaps in the record are visible. Assign a named reviewer, set a fixed review date, and keep the dated output of each run so the history shows continuous operation.
No exception approvals
Some accounts legitimately stay inactive for longer than 45 days, such as seasonal contractors or break-glass accounts. When these are kept enabled without a recorded decision, they are indistinguishable from neglected accounts. Require a written exception with a justification, an owner, an expiry date and an approver, and confirm that the enabled-dormant count in your measurement excludes only approved exceptions.
Questions buyers ask about Safeguard 5.3
How much effort does it take to disable dormant accounts?
The effort depends mostly on how many systems hold accounts and how many of them can report last-login data. A single directory with a reliable last-login attribute makes the work largely a matter of setting a rule and testing it. Effort rises when accounts live in many applications, when some applications have no inactivity setting, and when the team must first clear up accounts nobody can attribute to an owner. Safeguard 5.3 is an IG1 Safeguard, so it applies to every organization in scope, but the size of the account estate sets the workload. Ask any provider to break the estimate into discovery, rule design, rollout per system and recurring review.
Can we disable dormant accounts in-house without outside help?
Yes, many teams do this internally, and the Safeguard does not require a consultant. The work needs staff who can read the account inventory, change identity and application settings, and agree with business owners which inactive accounts can go. Outside help is most useful when the team lacks directory or identity engineering skills, when accounts sit in many platforms, or when the organization needs the rule documented and tested in a way that an assessor can follow. DeployOpen implements and documents self-hosted platforms in the client's own infrastructure, and it prepares systems and evidence. It does not issue assessment reports or certifications.
How long does it take to set up a 45-day dormant account rule?
No duration is published for this Safeguard, so treat any single number with caution. The timeline is driven by the state of the account inventory, the number of identity sources and applications, and the change process needed to disable accounts without breaking business services. A realistic plan separates the rule design from the rollout, because each application may need its own test cycle. Ask for a written schedule with milestones for inventory validation, a pilot system, a production rollout and the first review cycle, and confirm which of these depend on the client's own change windows.
What does the team need to supply for dormant account work?
The work needs named owners for each system and account type, read access to last-login data, and authority to disable or delete accounts. Safeguard 5.1 matters here because the CIS Controls Assessment Specification treats the account inventory as a prerequisite for measuring Safeguard 5.3. Teams also need a decision on exceptions, such as break-glass or seasonal accounts, and a record of who approved each one. Without these inputs, the rule may run but produce disputed results.
Will an auditor accept automated evidence for disabled dormant accounts?
An auditor can accept automated evidence when it is complete, time-stamped, reproducible and tied to the accounts in scope. Reports from a directory or identity provider showing last-login dates, the rule applied and the accounts disabled or deleted are typically stronger than screenshots. The assessor will still check that the report covers every system in scope and that exceptions are approved. Ask your auditor which formats and retention periods they expect before building the evidence pipeline. The organization owns its controls, and the auditor decides what it accepts.
Which open-source tools can help enforce dormant account rules?
Identity platforms can automate part of the work. authentik's SCIM provider pushes user creations, changes and deletions to target applications and deprovisions users when they lose access, which helps keep downstream accounts aligned with the source record. FreeIPA stores users and groups in a central directory with delegated administration, which gives one place to review account state. midPoint's access certification campaigns let designated reviewers decide whether to keep or revoke access, which supports periodic review of accounts that are still enabled. Confirm each tool's support for last-login tracking and inactivity rules in your target systems before you commit to a design.
What is the most common reason dormant account checks fail?
The most common failure is that some enabled accounts have no reliable last-activity record, so they cannot be measured as dormant or active. This happens with local accounts on servers, legacy applications and service accounts that run without interactive logins. The assessment specification counts enabled dormant accounts as a metric, so any account that cannot be evaluated becomes a gap to explain. Start by listing systems that do not record last use, then decide whether to add logging, move the account into a central directory or remove it.
How DeployOpen scopes and prepares Safeguard 5.3 evidence
DeployOpen works on Safeguard 5.3 as a fixed-scope engagement inside your own infrastructure, starting from the account inventory and the rules that define dormancy. We prepare the systems, the configuration and the evidence an assessor will sample, while your organization keeps ownership of the control and the decisions behind it.
How we scope
- Agree which directories, identity providers and applications hold accounts in the Safeguard 5.3 scope.
- Record the 45-day inactivity threshold, the last-login source for each system and the action (delete or disable) per account type.
- Confirm which systems do not support automated disablement, so manual procedures and their evidence are written into the scope.
How we build
- Configure the identity platform to flag or disable accounts once they pass the agreed inactivity threshold, where the platform supports it.
- Connect directory and application access so deprovisioning reaches target systems, using open-source tooling such as authentik SCIM provisioning.
- Build reports that count dormant accounts and enabled dormant accounts, the two metrics the assessment specification uses.
How we hand over
- Document the dormant account procedure, owners, exception handling and the review cadence in your own policy language.
- Deliver dated reports, configuration exports and change records that show the threshold was applied across in-scope systems.
- Walk your team through how to rerun the reports, so an assessor's sample can be reproduced without us in the room.
How we support
- Ongoing support, upgrades and continuous checks of dormant account reporting are available as a retainer after handover.
- Re-verify the threshold and reports after directory, application or identity platform changes that affect account activity data.
- Any independent assessment of Safeguard 5.3 is performed by your chosen assessor, since DeployOpen does not issue reports or certificates.
