Safeguard 16.11 Vetted security modules and services

What Safeguard 16.11 vetted security modules asks for and why teams miss it

Safeguard 16.11 asks the organization to rely on vetted modules or platform services for application security functions such as identity management, encryption, and auditing and logging, and, where encryption is involved, to use only standardized, currently accepted and extensively reviewed encryption algorithms. In practice, an application team that writes its own login flow, token handling, cipher routines or audit log writer is doing the work this Safeguard tells it not to do, unless no vetted option fits. Homegrown security code tends to fail in quiet ways: session handling that looks correct in tests but mishandles expiry, a custom cipher mode that is weak under a specific misuse, or log entries that omit the events an investigator needs. Few of these flaws show up in a functional test, which is why the Safeguard is written as a design rule rather than a scan result.

The requirement is hard for three reasons. First, most organizations cannot say which applications contain security code, because the software inventory under Safeguard 2.1 is often incomplete for internally built and legacy systems. The CIS Controls Assessment Specification treats that inventory as a prerequisite for measuring 16.11, so a gap there blocks the measurement itself. Second, legacy applications were built before the current modules existed, and retrofitting them is slower than writing new code. Third, ownership is unclear: the platform team may run the identity provider, the application team may still hold its own password checks, and nobody has been asked to reconcile the two. The Safeguard applies from Implementation Group 2, not IG1. It belongs to the Software asset class and the Protect security function, so the evidence sits with software records and the controls that protect them.

As a first action, list every application that handles sign-in, encryption keys, certificates or audit events, then record which vetted module or platform service each one uses and which custom code remains. Ask the assessor how they will count applications in the compliance metric, and confirm with your architecture group which encryption algorithms and library versions are approved. Teams that cannot name the approved list usually discover the gap during the assessment rather than before it.

Which applications, components and functions fall under 16.11

Safeguard 16.11 applies to the security functions your applications rely on, wherever those applications come from. The cards below cover the scoping choices that change the amount of work: where the software comes from, which security functions are involved, and which software inventory and implementation group settle the question.

In-house, hosted and acquired applications

Scope starts with the applications your teams build, the SaaS and hosted applications you use, and the packaged software you buy and run yourself. Each one may call its own identity, encryption or logging code. For in-house software, check whether developers wrote security functions from scratch. For acquired or hosted software, ask the vendor which security functions it implements and which it delegates to a platform service. Record the answer for each application, because the same function can be vetted in one product and hand-built in another.

Identity functions

Sign-in, session handling, single sign-on and token validation are the security functions most often rebuilt by application teams. Where an application can delegate sign-in to a shared identity provider through OAuth2, OpenID Connect, SAML, LDAP or a proxy provider, check whether it does. Where it cannot, the custom login code falls squarely in scope and should be reviewed as a vetted module candidate. Identity is the function most likely to be hand-built, so start the review here.

Encryption and cryptographic libraries

Cryptographic code is in scope wherever an application encrypts data, signs tokens, hashes passwords or manages keys. Most applications should call an established library rather than implement algorithms directly. Inventory which libraries each application loads, confirm they use standardized and currently accepted algorithms, and flag any custom cipher, hash or random number routine for replacement or formal review. Ask each owner which library versions are pinned and who tracks their advisories.

Audit logging functions

Logging that writes authentication events, authorization decisions and administrative actions is a security function under 16.11 when the application builds its own logging pipeline or log format. Check whether the application sends events to a central log platform through a supported library or agent, and whether timestamps, user identifiers and event types are consistent. Custom logging code that drops events or writes them to local files without integrity controls should be listed for review.

Third-party and platform services

Managed identity, key management and logging services that your applications call are in scope for the decision to use them, even though your organization does not operate their code. Record which services each application depends on, who owns the configuration, and what the service provider contract says about security responsibilities. Where a provider offers a platform service for a security function, the question for 16.11 is whether applications use it instead of a local replacement.

Software inventory and implementation group

The software inventory from Safeguard 2.1 is a prerequisite for measuring 16.11, because you cannot count vetted and unvetted components in applications you have not listed. Safeguard 16.11 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises and is out of scope for IG1 enterprises. Confirm your implementation group before building the scope, and treat the inventory as the source list for every card above.

How to move application security functions onto vetted components

This sequence takes an organization from an unknown set of in-house security code to a recorded decision for each identity, encryption and logging function, so Safeguard 16.11 can be measured against a complete inventory.

Build the software inventory first
Start with Safeguard 2.1, which the CIS assessment specification lists as a prerequisite for measuring 16.11. Platform or security engineering teams, working with application owners, list every application, service and library in scope, including the owner, language, hosting location and whether the code is in-house, acquired or hosted. The output is a software inventory extract with one row per application. The step is done when every application in scope has an owner and a source classification, and the owners confirm the list.
Identify security functions built in-house
Review each application's code and configuration for security functions it implements itself, such as password storage and login logic, session handling, token signing, cryptographic routines, access checks and audit log writing. Application security leads should record the function, the file or module where it lives and the team that maintains it. The output is a register of in-house security functions. The step is done when a reviewer has signed off that the register matches what the code actually does, including functions added by copied snippets or unofficial libraries.
Choose vetted identity services
For each identity function in the register, decide whether an established identity provider or a platform service will take over. Self-hosted options such as authentik, which acts as an identity provider through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, let applications delegate sign-in. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. Confirm each product's supported protocols against the application's needs. The output is an identity decision record that names the chosen service, the protocol for each application and any gaps that need a custom integration. The step is done when security and architecture owners approve it.
Choose vetted encryption and logging services
Repeat the decision for encryption and audit logging. For encryption, identify the libraries or platform key services the applications should call rather than custom cipher code, and confirm who owns key management. For logging, choose the shared logging platform and the event format applications must emit. Document the owner of each service. The output is a decision record for encryption and logging, listing the approved service or library, its maintainer and the applications it covers. The step is done when each application in the register maps to a named service in both categories.
Standardize approved cryptographic algorithms
Write a short standard that lists the algorithms and modes applications may use, limited to standardized, currently accepted and extensively reviewed algorithms as Safeguard 16.11 asks. Security architects draft it, and the security governance owner approves it. Include a rule that no team may introduce a custom cipher or hash scheme. The output is an approved cryptographic algorithm standard with a version number and an owner. The step is done when the standard is published and each in-scope application is checked against it, with exceptions recorded in writing and given an owner and review date.
Migrate applications to the vetted components
Plan migrations by application risk and dependency order, starting with the functions that carry the most exposure. Developers replace in-house code with calls to the approved services, remove the old code paths and keep regression tests running. Source control controls such as those in GitLab Community Edition, including protected branches that limit who can push or merge, help record and review each change. Semgrep Community Edition can scan repositories in CI/CD pipelines for leftover custom security code. The output is a migration log with one entry per application, showing the function replaced, the change reference, the test result and the reviewer. The step is done when the log shows no open items for in-scope applications.
Record the decision and status of each component
Maintain one register that links each security function, its chosen vetted component, the cryptographic standard it follows, the migration status and the evidence, such as the inventory row, decision record and migration entry. Review it on a schedule the organization sets and on any significant change. The output is a current component register with status fields for each function. The step is done when an assessor can trace a sample of applications from the inventory to the register to the migration log without asking the team for undocumented explanations. Ask an independent auditor which format they expect before you finalize the register.

How an assessor tests 16.11 with the Compliance metric

This table walks through the assessment steps an assessor follows against the Compliance metric for Safeguard 16.11, the evidence each step relies on, and the findings that most often cause a shortfall. Read it as a checklist for preparing your own evidence before an independent assessment begins.

Assessment step	What the assessor checks	Evidence that satisfies it	Common finding
Confirm the component inventory	Whether the organization knows which application security components exist, including identity, encryption and audit logging functions, before measuring them	A software inventory under Safeguard 2.1 that lists in-scope applications and the security components they use	Inventory covers applications but omits libraries, sidecars or SaaS-delegated functions
Identify components where vetted options exist	Which security functions have a vetted module or platform service available that the organization could use instead of custom code	Written list of security functions per application and the vetted options considered for each	No documented review, so teams assume custom code is the only option
Check delegation to vetted services	Whether identity, encryption and logging run through a vetted module or platform service in the applications sampled	Configuration of the delegated service, such as identity provider settings for each application's sign-in flow	Applications still run local password tables or bespoke login logic beside a central identity service
Review encryption algorithm settings	Whether the algorithms and key lengths in use are standardized, currently accepted and extensively reviewed	Cipher suite and algorithm configuration files, TLS settings and library version records	Deprecated algorithms or weak modes left enabled for compatibility
Sample applications	Whether the sampled applications match the organization's own claims about delegation and algorithm use	Selected applications with their code references, configuration exports and build records for the sample	Sample reveals one application with a custom authentication routine that the inventory did not record
Score the Compliance metric	The share of application security components that use vetted modules or services where available	Ratio worked out from the component list and the sampled results, with the basis for each exclusion recorded	Exclusions made without a documented reason, which assessors usually reject

Which evidence shows vetted modules are used and algorithms are approved

The evidence that passes for Safeguard 16.11 is a set of records that let an assessor trace every application security component back to a vetted module or platform service and confirm that the cryptographic choices are approved. The starting point is an application security component register, linked to the software inventory that Safeguard 2.1 requires, since the CIS Controls Assessment Specification treats that inventory as a prerequisite for measuring 16.11. Each row should name the component, its owning application, whether it is a vetted module, an identity or logging service, or an in-house function, and the source it was taken from. Assessors use this register to calculate the Compliance metric, which is the share of components that use vetted modules or services where those are available, so an in-house function needs a recorded reason for not using the platform option.

The register alone does not prove delegation, so pair it with configuration exports. For identity, export the application settings that point sign-in to the identity provider, such as the OpenID Connect client registrations or SAML metadata. For logging, export the forwarding configuration that sends application events to the central log platform. For encryption, keep a cryptographic standard document that names the approved algorithms, key lengths and modes, and states that only standardized, currently accepted and extensively reviewed algorithms are permitted. Confirm with your assessor which export format and retention period they expect, because the assessment specification defines what to measure and leaves the method to you.

Exceptions are where many programs fail the test. Every component that uses a custom or deprecated approach needs a written exception with a named risk owner, a compensating control, an expiry date and a review trail. Keep these current between audits by attaching register updates to change tickets, re-exporting configurations after each release, and running a periodic review of the register and the cryptographic standard, with the review date and outcome recorded. The organization owns this evidence and is accountable for its accuracy. The independent auditor or assessor tests it, and DeployOpen, when engaged, prepares the systems and records but does not issue any conclusion about them.

Which self-hosted open-source tools produce 16.11 evidence

Safeguard 16.11 is satisfied by the identity, access and code review records that show which vetted components an application relies on and who approved changes to them. The tools below each produce one part of that record, and none of them decides on its own whether the Safeguard is met. Confirm each license and feature fit for your environment before relying on it.

Identity delegation with authentik

authentik is an identity provider that applications can delegate sign-in to through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. Under 16.11, this lets teams avoid writing their own login and session code and point the assessor to one vetted, configured identity component. Check which protocols your applications need, confirm that each application is actually registered as a provider, and keep the provider configuration under change control. Confirm the MIT license terms apply to the edition and modules you deploy.

Central single sign-on with FreeIPA

FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, so host and service authentication draws on one shared component rather than local accounts. For 16.11, this is evidence that identity functions on Linux and UNIX hosts come from a maintained, centrally managed platform. Confirm which hosts and services can authenticate against it, and note that its GPL-3.0-or-later license has obligations that your legal team should review before distribution or modification.

Component change control in GitLab

GitLab Community Edition protected branches let maintainers restrict which roles can push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. For Safeguard 16.11, the branch settings and their history show who can change the code that wires in vetted modules, which is the change record an assessor will ask for. Confirm that protection covers the default and release branches, and review who holds maintainer rights.

Custom rule checks with Semgrep

Semgrep Community Edition scans code in many languages, including Java, JavaScript, Python, Go and Terraform, using community or custom rules. Custom rules can flag application code that reimplements security functions such as hand-rolled cryptography or local password checks instead of calling an approved module. The scan can run in CI/CD pipelines so that every merge is checked. Its LGPL-2.1-only license and the rule coverage for your languages should be confirmed before you rely on it as evidence.

What meeting 16.11 costs in money and effort

This table breaks down the cost components of meeting Safeguard 16.11 by who is paid, whether each cost is one-time or recurring, and what pushes it up or down. No prices are given because none are supplied for this Safeguard, so use the table to shape a written scope and quote. The main takeaway is that the largest variable cost is usually migrating applications to vetted modules, not the modules themselves.

Cost component	One-time or recurring	What drives it up or down
Module or platform licenses	Recurring if commercial; none for supported open-source platforms	Commercial identity, encryption or logging products price on users, applications or volume. Open-source modules remove license fees but not support costs. Confirm each vendor's terms in writing.
Engineering time to migrate applications	One-time, sometimes phased over several releases	Driven by the number of applications with custom security code, legacy code that cannot easily call a standard library, and the number of teams that own those applications.
Identity integration	One-time per application, plus recurring changes	Applications that support OAuth2, OpenID Connect or SAML integrate faster than applications needing LDAP or proxy-based sign-in. Each new application adds a repeat of this work.
Audit logging integration	One-time, then recurring as log formats change	Depends on how many applications emit security events, whether logs already reach a central store, and how much schema mapping the security team needs.
Encryption algorithm review and cryptographic library updates	Recurring	Driven by the number of cryptographic uses in the estate and how often standards change. Keeping a record of approved algorithms reduces rework at each review.
Evidence upkeep (inventory, approved module list, test records)	Recurring	Rises with the number of application security components and the frequency of review. It falls when the software inventory required by Safeguard 2.1 is already current and automated.
External review or penetration testing	Recurring, usually tied to a test cycle	Scope depends on how many applications use custom security functions and whether the test covers authenticated business logic. Ask the tester to name the components in scope.
Auditor sampling and assessment support	Recurring, per assessment cycle	Set by the assessor's sample selection, the number of applications in scope and how easily evidence can be produced. Clear inventory and records shorten the work.
Implementation partner scope	One-time, with optional recurring support	Fixed-scope work covers the agreed applications, integrations and evidence. Ask for the list of applications, the systems touched and what the partner will not do.

Who owns 16.11 work: your team, a partner and the auditor

Your organization owns Safeguard 16.11. Only you can decide which identity, encryption and logging components are approved for application use, which algorithms are permitted, and who accepts the residual risk when a component is not vetted. These decisions belong in a documented standard that security and engineering leaders sign off on, and they must be revisited when components or algorithms change.

Approved component register: Maintain the list of identity, cryptography and audit logging modules or platform services that application teams may use, with the owner and review date for each.
Algorithm standard: Name the standardized, currently accepted and extensively reviewed encryption algorithms and the key lengths and modes that apply, and retire anything that falls out of use.
Software inventory link: Keep the software inventory from Safeguard 2.1 current, since it is the prerequisite for measuring which application components use vetted modules.
Exception approvals: Record who may approve a custom security function, what review it needs and when it expires.
Operational ownership: Assign people to patch, upgrade and monitor the self-hosted platforms you run.

Check that your register and standard exist as signed documents, that each application's security components map to an entry, and that exceptions have dated approvals.

Where teams fall short on 16.11 and how to close each gap

Most gaps against Safeguard 16.11 are not about missing security libraries. They come from teams not knowing which applications use security functions, which components they rely on, and who decides. The cards below cover the gaps assessors most often find and the closing action for each.

No software inventory to scope from

Safeguard 16.11 is measured against application security components, and the assessment specification lists Safeguard 2.1, the software inventory, as a prerequisite. Without an inventory, teams cannot say which applications implement identity, encryption or logging themselves. Close the gap by building the inventory first, then tagging each application with the security functions it performs and whether it uses a vetted module or service.

Custom authentication in legacy apps

Older line-of-business applications often ship with their own login forms, password storage and session handling. Each one is a home-grown security function that a reviewer must examine separately. Check which legacy applications authenticate users locally, then plan to place them behind a shared identity provider, such as authentik acting as a proxy or OAuth2 and OpenID Connect provider, where the application can support it.

Encryption choices set per developer

When each developer picks a cipher, hash or key length, the organization cannot show that only standardized, currently accepted and extensively reviewed algorithms are in use. Set one approved algorithm list and a single vetted cryptographic library per language, and make that list the reference for code review. Ask each team to confirm in writing which libraries their applications call for encryption.

Logs that miss security events

Applications that write logs only for errors cannot show authentication failures, privilege changes or access to sensitive records, which are the events an assessor expects to see. Confirm which security events each application's audit logging library records and where those events are sent. Then test one failed login and one permission change end to end to confirm they reach the central log store.

Undocumented exceptions to standard components

Teams often bypass the approved module for a good reason, such as a performance constraint or a vendor limitation, and never record it. An undocumented exception is indistinguishable from a control gap during assessment. Require a short exception record for each case that names the component used, the risk accepted, the owner and a review date, and keep these records with the software inventory.

No owner for component decisions

When no one is accountable for choosing identity, encryption and logging components, each project makes its own choice and the choices drift apart over time. Assign a named owner, usually in the security architecture or platform engineering function, with authority to approve new security components and retire old ones. Record that owner in the secure development process documentation covered by Safeguard 16.1.

Questions buyers ask about 16.11 cost, effort and scope

What drives the cost of meeting Safeguard 16.11?

The cost depends mainly on how many application security components the organization runs and how many of them already use vetted modules or services. Most of the spend is staff time: someone must build the list of identity, encryption and logging functions, check where each application implements its own version, and move those functions to approved components. Costs rise with the number of in-house applications, the number of custom cryptographic or authentication code paths, and the number of teams that own them. Costs fall when a single identity provider or logging platform already serves most applications. Ask any quote to itemize discovery, migration work per application, testing, and documentation, and to state which items are one-time and which recur, such as upgrades and access reviews.

How long does it take to implement 16.11?

No supplied fact gives a duration, so the honest answer is that it depends on the application estate. The work runs in stages: confirm the software inventory that the assessment specification treats as a prerequisite through Safeguard 2.1, identify the application security components in scope, decide which vetted module or service replaces each custom function, migrate, and then collect evidence that the share of components using vetted options holds over time. Ask any implementation partner for a timeline built from a written scope, and ask the internal team which applications have the most custom security code, since those usually set the critical path.

What does 16.11 need from our internal team?

The work needs owners who can make decisions, not only hands on keyboards. Application owners must confirm which functions their software implements, security architects must approve the vetted modules and the encryption algorithms they use, and platform or identity teams must run the shared services once they are in place. Operations staff keep the services patched and monitored. Procurement and legal may also be involved if a managed service is chosen. Ask the implementation partner to name which roles it needs from your side, how many hours of their time each role should expect, and who signs off each migration.

Can a small team implement 16.11 on its own?

A small team can do it on its own when the application estate is small and it already has people who understand authentication, cryptography and logging. Difficulty rises when applications are custom, when several of them each contain their own identity or encryption code, or when no one maintains a current software inventory. A small team should first confirm it can name every application in scope, then pick one shared identity provider and one logging approach, and migrate the highest-risk applications first. If the team lacks cryptography or identity skills, a fixed-scope engagement can cover that gap, but the organization still owns the decisions and the resulting controls.

Do IG1 organizations need Safeguard 16.11?

No. Safeguard 16.11 is assigned to Implementation Group 2 and Implementation Group 3, so it applies to IG2 and IG3 enterprises but not to IG1 organizations. An IG1 organization should still avoid writing its own cryptography or authentication code where a standard option exists, because that is good practice, but it is not measured against this Safeguard. Confirm your Implementation Group against the CIS Implementation Groups pages before scoping work, since the grouping decides which Safeguards an assessor will test.

What will an assessor ask for to test 16.11?

An assessor will expect a current software inventory, a list of application security components in scope, and evidence of which components use vetted modules or services. The CIS Controls Assessment Specification scores Safeguard 16.11 with a Compliance metric, the share of application security components using vetted modules or services when available, so the assessor will calculate that share from your records. Expect requests for the approved encryption algorithms, configuration exports from identity and logging services, and exceptions for components where no vetted option existed. Organizations should confirm the exact evidence format with their assessor, because the CIS specification explains what to measure but not how.

What does an implementation partner do and not do for 16.11?

An implementation partner plans the work, deploys and configures self-hosted open-source platforms such as an identity provider or directory service, integrates applications with them, documents the configuration, and prepares the evidence the organization needs. DeployOpen works this way: it implements inside the client's own infrastructure under a written, fixed scope. It does not own the controls, decide the organization's risk tolerance, or issue an assessment result. Only the organization owns its controls, and only an independent auditor or assessor issues a report or certificate. Ask any partner to state these boundaries in the statement of work.

Which open-source tools can support 16.11 evidence?

Several open-source platforms can produce the records an assessor asks for, though each must be confirmed in your environment. authentik acts as an identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications can delegate sign-in to it instead of implementing their own. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. Semgrep Community Edition can scan code for insecure custom security functions in CI/CD pipelines, which helps identify components that should move to vetted options. Confirm each tool's supported protocols and integration path with its documentation before committing.

How DeployOpen scopes and prepares 16.11 evidence

DeployOpen works on Safeguard 16.11 as part of a fixed-scope engagement that starts with a written scope agreed before work begins. We prepare the systems, configuration and records that show application security functions rely on vetted modules or services, while your organization keeps ownership of its controls and an independent assessor reaches any conclusion about them.

How we scope

Agree in writing which applications and security functions fall under 16.11, such as identity, encryption and audit logging.
Confirm that the software inventory required by Safeguard 2.1 is in place before measuring 16.11 coverage.
Define which Implementation Group applies, since 16.11 sits in IG2 and does not apply to IG1 enterprises.

How we build

Map each in-house security function to the vetted module or platform service it should use, and record the exceptions.
Set up self-hosted platforms such as authentik or FreeIPA where they fit the agreed scope, and document their configuration.
Restrict approved encryption algorithms in code and configuration, and test that weaker or nonstandard options are not in use.

How we hand over

Deliver the component register, configuration records and test results that support the Compliance measure in the assessment specification.
Document the procedures your staff need to keep the vetted components current and to approve any new custom security code.
Provide a handover session so your team can explain the evidence to internal reviewers and to the independent assessor.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, if your organization wants it.
Review the component register when new applications or security functions are added to the environment.
Confirm with your assessor which evidence format they expect, since DeployOpen prepares evidence but does not issue reports or certifications.