Category: Cryptography & Encryption

Approved Security Functions

Simply put

Approved security functions are the specific cryptographic and security mechanisms that an authoritative body has vetted and permitted for protecting sensitive information. Organizations are generally expected to use these approved functions rather than unvetted or proprietary alternatives when safeguarding data. The exact list of approved functions depends on the governing standard and revision that applies to a given system.

Formal definition

Approved security functions generally refers to the set of cryptographic algorithms, modes, and related security mechanisms that have been evaluated and sanctioned by a governing authority for use in protecting information within a defined scope, such as federal information systems handling CUI or national security systems. In practice, implementations are expected to rely on these vetted functions, rather than non-validated or proprietary alternatives, to meet applicable confidentiality and integrity requirements. The precise set of approved functions, the authority maintaining the list, and any validation obligations vary by the applicable standard and revision; readers should confirm the specific approved functions and their status against the current authoritative text governing their system, as this entry does not establish particular algorithms, control numbers, or validation program details.

Why it matters

Approved security functions establish a baseline of trust for how sensitive information is protected. When an authoritative body vets a cryptographic algorithm or security mechanism, it provides assurance that the function has been examined against recognized criteria rather than relying on the unproven claims of a vendor or an internally developed scheme. For organizations handling Controlled Unclassified Information (CUI), national security systems, or other regulated data, using approved functions rather than proprietary or non-validated alternatives is generally a precondition for meeting applicable confidentiality and integrity requirements. Deploying an unvetted algorithm can leave data exposed to weaknesses that a formal evaluation process is designed to surface.

The practical significance also lies in accountability and consistency across systems. A commonly repeated expert caution is that selecting an approved algorithm is not the same as implementing it correctly or having that implementation validated; using an approved function does not by itself guarantee security, nor does it substitute for the broader authorization and continuous monitoring obligations that govern a system. Compliance officers and system security managers should treat the approved-functions requirement as one element of a layered control set rather than as a standalone assurance.

Because the specific set of approved functions, the authority that maintains it, and any associated validation obligations vary by governing standard and revision, teams that assume a fixed or permanent list can drift out of compliance as guidance evolves. Functions can be added, deprecated, or restricted over time. This entry does not establish particular algorithms, control numbers, or validation program details, so readers must confirm the current status of any function against the authoritative text governing their system.

Who it's relevant to

Information System Security Managers and Engineers

Those responsible for designing and maintaining systems that protect sensitive information need to ensure the cryptographic and security mechanisms in use fall within the approved set defined by the governing standard. They should verify the current status of each function against the applicable revision rather than assuming a previously approved function remains sanctioned, and should recognize that selecting an approved function does not by itself confirm correct or validated implementation.

Compliance Officers and Auditors

Personnel assessing whether a system meets applicable requirements need to confirm that approved security functions are used where required and to identify reliance on non-validated or proprietary alternatives. They should anchor findings to the specific governing text and revision that applies to the system in question, since the approved set and any validation obligations vary across standards and revisions.

Government Contractors Handling CUI or National Security Data

Contractors safeguarding CUI or supporting national security systems are generally expected to use approved functions rather than unvetted alternatives. Scope boundaries matter here: the functions and obligations that apply can differ between federal civilian, defense, and national security contexts, and contractors should confirm the requirements tied to their specific data type and contract against current authoritative sources.

Authorizing Officials

Officials making risk-based authorization decisions should understand how the use of approved security functions supports, but does not replace, the broader authorization and continuous monitoring process. Confirming that a system relies on vetted functions is one input to a decision; it is not equivalent to a security guarantee, and the underlying approved set may change under newer revisions during a system's operational life.

Inside Approved Security Functions

Cryptographic Algorithm Validation

Approved security functions generally refer to cryptographic algorithms and modes that have been validated against recognized federal standards, such as those referenced in NIST publications. Validation typically occurs through programs administered by NIST rather than through vendor self-attestation alone. Readers should confirm the current list of approved functions against the applicable NIST guidance, as approved algorithms and key lengths change across revisions.

Module Validation Context

The concept is often tied to the validation of the cryptographic module in which a security function operates, not merely the algorithm in isolation. An algorithm may be approved while a particular implementation is not validated. Practitioners should distinguish an approved security function from a validated cryptographic module, since the two are related but distinct considerations.

Applicability to Controls

Approved security functions are frequently invoked by control requirements within control catalogs such as NIST SP 800-53, and by CUI protection requirements such as those in NIST SP 800-171. The specific control language and applicability depend on the system category, impact level, and any agency tailoring, so the governing baseline should be checked directly.

Scope Boundaries

Requirements to use approved security functions may differ across federal civilian systems under FISMA, DoD systems under the RMF, systems handling CUI, and classified systems governed by separate national security authorities. State, local, tribal, and territorial obligations may differ. The precise obligation depends on which authority governs the system in question.

Common questions

Answers to the questions practitioners most commonly ask about Approved Security Functions.

Does using an approved security function guarantee that my system is secure or compliant?

No. The approval of a security function refers to whether a cryptographic or security mechanism has met the criteria of the relevant validation program, not to whether your overall system is secure or compliant. Compliance and security are distinct from the selection of an approved function: a validated algorithm can still be implemented incorrectly, configured insecurely, or deployed in a system that fails other control requirements. Approved security functions are one input into a broader control implementation and assessment process, and their presence does not, by itself, satisfy an authorization or continuous monitoring obligation.

If a security function appears on an approved list, does that mean any product using it is automatically validated?

Not necessarily. There is an important distinction between an approved security function (the underlying algorithm or mechanism) and a validated implementation of that function within a specific product or module. An algorithm can be approved in principle while a given product's implementation has not been independently tested or validated. Readers should confirm both that the function is approved under the applicable program and that the specific implementation carries the appropriate validation, verifying details against current authoritative sources rather than assuming coverage from an algorithm listing alone.

How do I determine which security functions are considered approved for my system?

The set of approved security functions generally depends on the governing framework and impact level applicable to your system, and the tailoring applied by your agency or authorizing official. Because approved lists and their supporting standards are maintained by specific bodies and can change across revisions, you should identify the controls and baselines that apply to your system, then consult the current authoritative documentation referenced by those controls. Confirm the applicable revision and any agency-specific interpretations rather than relying on a static list.

What should I do when a previously approved security function is deprecated or withdrawn?

Approved status is not permanent, and functions may be deprecated, restricted to legacy use, or withdrawn as standards evolve. In most implementations you would identify where the affected function is used, assess the impact on your controls, and plan a transition to a currently approved alternative consistent with your organization's change management and continuous monitoring processes. Because timelines and transition requirements depend on the governing publication and any agency tailoring, verify the current guidance and any effective dates against the authoritative source.

How do approved security functions relate to the controls in my security control baseline?

Approved security functions are generally referenced by controls that call for cryptographic or security mechanisms, and the applicable baseline determines which controls apply to your system. The baseline and its tailoring establish the requirement to use approved functions in specified circumstances, while the approved-function guidance identifies which mechanisms satisfy that requirement. This entry does not cover the implementation, contractual, or assessment specifics for any particular control, which you must confirm against the current authoritative control set and your assessment procedures.

How should the use of approved security functions be documented for assessment?

In most implementations, the security functions in use are documented within system security documentation so that assessors can verify that applicable controls are met. This typically includes identifying where such functions are used and providing evidence that the functions and their implementations meet the applicable approval and validation requirements. Assessment is distinct from authorization, so documenting approved functions supports the evidence an assessor reviews but does not by itself confer an Authority to Operate. Confirm the specific documentation and evidence expectations with your assessment guidance and authorizing official.

Common misconceptions

Any strong or widely used encryption algorithm qualifies as an approved security function.

Strength or popularity does not establish approval. A security function is generally considered approved only when it aligns with the algorithms, modes, and parameters recognized in the applicable federal standards. Approved lists change across revisions, so the current authoritative NIST guidance should be verified rather than assumed.

Using an approved algorithm is the same as having a validated cryptographic module.

An approved algorithm and a validated module are distinct. An implementation can use an approved algorithm without the module itself being validated. Practitioners should confirm both the approval of the function and the validation status of the specific implementation as required by their governing controls.

Meeting the approved security function requirement means the system is compliant and secure.

Compliance with a single requirement is not equivalent to overall compliance or to security. Approved security functions address one aspect of protection; authorization, continuous monitoring, and the full applicable control set still apply. Compliance and security are not interchangeable.

Best practices

Verify the current list of approved algorithms, modes, and key parameters against the applicable NIST publication, since approved functions and deprecated algorithms change across revisions.

Confirm not only that an algorithm is approved but also that the specific cryptographic module implementation meets any applicable validation requirement.

Identify the governing authority for the system (for example FISMA for civilian systems, the RMF for DoD systems, or CUI protection requirements) and apply the correct requirement for that scope rather than assuming a single uniform standard.

Trace each approved-security-function obligation back to the specific control or requirement in the relevant baseline, accounting for impact level and any agency tailoring.

Document the basis for each cryptographic selection, including references to the authoritative source, to support assessment and authorization activities.

Treat approved security function selections as subject to change, and revisit them during continuous monitoring as standards, revisions, and deprecations evolve.