SC-29 Heterogeneity: requirements and evidence

What SC-29 heterogeneity asks and why it sits outside every baseline

SC-29 requires an organization to use a diverse set of information technologies for defined system components, so that one exploited vulnerability does not compromise every component of a system. It is not in any SP 800-53B baseline (low, moderate, high or privacy), so it applies only when you select it through tailoring or an overlay. If someone has told you SC-29 applies to your system, ask which baseline, overlay or contract clause brought it in, and whether the organization-defined parameter for the component set has been filled in. Without a defined scope, an assessor has nothing to test against.

The risk is monoculture. When every server, hypervisor, endpoint agent, network device or cryptographic library comes from one vendor and one code base, a single flaw or a single supply chain compromise can reach every part of the environment at once. Appendix C of SP 800-53 Rev. 5 lists SC-29 as implemented by the organization (O) rather than inherited from a shared service, and it is marked as an assurance-related control. That means the organization decides which components need diversity, documents the decision, and produces the design and configuration records that show it was carried out. Confirm the Appendix C entry and the current control text in the SP 800-53 Rev. 5 publication before you cite it in a plan.

The difficulty is that diversity works against almost every pressure in IT. Standardization lowers patching effort and training cost, consolidated procurement lowers unit prices, and a single platform is easier to monitor and support. Introducing a second operating system, database or firewall vendor adds licensing, skills, integration and testing work that recurs for the life of the system. Start by listing the components where a common-mode failure would be most damaging, such as identity, boundary and backup infrastructure, and ask your architects and procurement team to price the diverse option against the standardized one. The organization owns that trade-off, and the decision should be recorded in the system design documentation that an assessor will examine.

Which systems, components and contracts fall under SC-29 once selected

SC-29 has no baseline default, so the work starts with a scoping decision: which components the organization defines as diverse, who owns them and which contracts carry technology choices into the boundary. The cards below cover those decisions in the order an assessor will ask about them.

Defining the diversity scope

SC-29 asks the organization to define the system components that must use a diverse set of technologies, and that definition is the organization-defined parameter the assessor reads first. Write the list by component class, such as servers, endpoints, network devices, hypervisors and databases, and name the platform or vendor family used for each. A vague scope such as "all infrastructure" is hard to test and hard to defend, so state exactly which classes are in and which are out.

Infrastructure and platform owners

Diversity is usually decided by the teams that buy and run the components: infrastructure, network, endpoint, database and virtualization owners. Each owner must confirm which technologies they run and whether a second, different technology exists for the same function. Without named owners, the scope becomes a document no team maintains, and the configuration evidence that assessors examine goes stale.

Hypervisors, databases and network devices

These components often concentrate risk because one vendor's platform can sit under many workloads. For each class, record the product, version and vendor in the inventory, and state whether the organization runs more than one technology for that function. Asset inventories such as GLPI or the Wazuh Syscollector module can supply the list of technologies deployed in the system, which is one of the examine objects for SC-29.

Acquisition contracts and managed services

Technology choices enter the system through purchase orders, managed service agreements and cloud contracts, not only through internal design. Review acquisition contracts for the product, platform and version the supplier will deliver, and record any clause that fixes a single technology stack. Assessors look for acquisition contracts for system components or services as evidence, so the diversity decision should be visible there and not only in architecture diagrams.

Third-party and hosted services

Hosted DNS, email gateways, identity providers and outsourced monitoring can make the same technology choice for many customers and therefore sit inside the diversity question. Ask each provider which platforms underpin the service and whether it can be replaced with a different technology if needed. Where a provider cannot answer, record the gap as a risk in the system security plan rather than assuming diversity exists.

Confirming the FedRAMP position

FedRAMP's Rev5 baselines do not require SC-29 at Class B, C or D, so a FedRAMP-bound system may treat it as optional. The organization still needs to confirm its own authorizing body, contract terms and any overlay before dropping the control. Document the decision and its basis, because an assessor will test the organization's stated selection, not the FedRAMP baseline alone.

How diverse technologies stop one flaw from reaching every component

A fleet built on one operating system, one hypervisor, one browser engine or one library version shares every vulnerability in that technology. SC-29 Heterogeneity asks the organization to use a diverse set of information technologies for defined system components, so that a single exploited flaw does not compromise all of them. The mechanism is blast radius. If the web tier runs one Linux distribution and one container runtime, a kernel or runtime exploit reaches every web node at once. If the defined components are split across two or more platforms, an attacker who succeeds on one may find the others resist the same technique. The control is not in any SP 800-53B baseline, so it applies only when the organization selects it through tailoring or an overlay. Start by asking which components the organization would least want to share a flaw, such as identity services, boundary devices or backup infrastructure, and document the decision in the system security plan.

The trade-offs are real and the reader should price them before committing. Every additional technology adds a patch stream, a hardening baseline, a monitoring configuration and staff who can operate it. Diversity can also increase misconfiguration risk if teams are thin. Before selecting SC-29, confirm with the system owner how many distinct platforms the team can patch within its existing change windows, and whether open-source components in the mix are supported by a named maintainer or vendor. Keep in mind that SP 800-53A assesses SC-29 by examining the list of technologies deployed in the system, acquisition contracts, design documentation and configuration settings, so the inventory from tools such as GLPI or the Wazuh Syscollector module is useful evidence of what is actually running.

Several related controls address the same design question, but none of them is a substitute for SC-29. SC-27 (platform-independent applications) asks for applications that can run across platforms so critical functions survive when one platform is compromised. SC-30 (concealment and misdirection) reduces an adversary's ability to target a known configuration. SR-3 (supply chain controls) governs where diverse components come from, and AU-9 (protection of audit information) and PL-8 (security and privacy architectures) govern how audit records and architecture decisions are protected and documented. These controls are listed here for context only. Each needs its own implementation and evidence, and an assessor will test them separately from SC-29.

How an assessor tests SC-29 and what they ask to see

This table walks through the single SP 800-53A Release 5.2.0 determination statement for SC-29 and shows, method by method, what an assessor examines, asks and tests. Read each row as a request the assessor will make, paired with the evidence that answers it and the findings that usually appear when the evidence is missing or inconsistent.

Assessment method	What the assessor does	Evidence that passes	Common findings
Examine: list of technologies deployed	Compares the defined technology diversity against the list of technologies actually deployed in the system	A current technology list that maps each diverse component to its platform, vendor and version, reconciled with the asset inventory	The defined component list does not match the inventory, or the list omits services added after the last review
Examine: acquisition contracts	Checks whether contracts for system components or services allow the organization to source diverse technologies	Contract clauses that permit alternate suppliers or products, with terms for substitution and exit	A contract locks in one technology stack with no substitution path, so the diversity decision cannot be carried out
Examine: system design documentation	Reads the architecture to confirm where diversity was chosen and why it reduces shared exposure	Architecture diagrams and design decisions that show which components use different technologies and which shared dependencies remain	A diversity decision is undocumented, or the design says diversity exists but does not identify the components it covers
Examine: configuration settings and associated documentation	Compares configuration baselines to confirm that components run the technologies the design describes	Configuration records and baselines for each diverse component, with change history that matches the design	Configurations drift to a common operating system, library or image, so the diversity no longer exists in practice
Interview: system owner and architects	Asks how the diversity was selected, who approves changes to it and how it is kept current	Consistent answers from the system owner and architects that match the design and contract records, with named approvers	Owners and architects describe different components, or no one can say who reviews a change that would remove diversity
Test: defined diversity in the deployed configuration	Samples deployed components and checks their actual technologies against the documented diversity	Scan or inventory output, collected by an agent or tool, showing deployed technologies that match the documented decision	Testing finds several components on the same technology that the design describes as separate, so the defined diversity does not exist
Test: scope of shared dependencies	Looks for shared components such as identity services, libraries or management tools that could defeat the diversity	A dependency list that identifies common components and records an accepted risk or a plan for them	Shared management plane or identity service is not documented, and a single exploit could reach every diverse component

How to implement SC-29 in a self-hosted environment, step by step

This sequence takes SC-29 from a selection decision to a documented, maintained record of the technology diversity an assessor can examine. Each step produces an artifact that the organization owns and that an independent assessor can test.

Confirm SC-29 is selected in the tailored baseline
Start by checking whether SC-29 appears in your system's tailored control set. SP 800-53B does not assign SC-29 to the low, moderate, high or privacy baseline, so it is present only if your authorizing official, contract or overlay selected it. The system owner records the decision in the system security and privacy plan, and the output is a tailored baseline entry for SC-29 that names the organization-defined parameter values or states that the control is not selected with a reason. If no one can point to that entry, stop here and resolve the selection before doing further work.
Define the organization-defined components
SC-29 requires diversity for components you define, so the security architect and system owner agree which system components the requirement covers. Typical candidates are operating systems on critical hosts, hypervisors, load balancers, firewalls, identity services and database engines, but the list must come from your own architecture and risk decisions. The output is a component list with an owner for each entry and the reason it is in scope. Keep the list in version control so later changes are visible.
Inventory the technologies each component uses
For each listed component, record the product, version, vendor, underlying platform and the dependencies it shares with other components. An inventory tool helps here. GLPI's Assets module can hold computers, software, network equipment and racks, and its GLPI Agent can push inventory data automatically. Wazuh's Syscollector module collects operating system, installed software, network interfaces, services and running processes from each endpoint. The output is a technology inventory that shows which components share an operating system, hypervisor, library or vendor, and it becomes the input for the next decision.
Decide where diversity is required and document why
Using the inventory, identify single points of shared technology where one exploited vulnerability could affect several components at once. For each, the architect decides whether to introduce a different technology, keep the shared one with compensating controls, or accept the concentration as a documented risk. Record the decision, the threat or failure scenario it addresses, the alternatives considered and the approver. The output is a design decision record for each component. Assessors use this record to see that the choice was deliberate rather than accidental, so vague rationales such as "standard practice" will not carry much weight.
Align acquisition and change processes to keep the mix
A diverse architecture can drift back to uniformity when a team standardizes on one product or a new component is bought for convenience. Update your acquisition checklist, change request template and architecture review step so that proposed components are compared against the design decision record before approval. Procurement and platform engineering own this check. The output is an updated change procedure and a review entry in the change log showing that the diversity rationale was considered for each new or replaced component.
Record configuration and design evidence
Gather the artifacts an assessor will examine for SC-29: the list of technologies deployed in the system, acquisition contracts or purchase records for the components, system design documentation, and configuration settings with their associated documentation. Store them under the system's evidence repository with dates and owners, and reconcile them against the inventory so they agree. The output is an evidence package that can be traced from the tailored baseline entry through the design decision record to the deployed configuration. Ask your independent assessor early which specific artifacts they expect, because the examine methods in SP 800-53A set the minimum they will request.

Evidence that passes an SC-29 review and how to keep it current

SC-29 is assessed by examining a short list of artifacts, so the evidence is only as useful as its currency. The cards below map each artifact to an SP 800-53A examine object and describe how to refresh it between assessments. No single artifact demonstrates the control on its own; an assessor will expect them to agree with each other.

Technology inventory export

This is the list of technologies deployed in the system, the first examine object SP 800-53A names for SC-29. Export the component inventory with operating system, platform, database, hypervisor and key library versions, and record the vendor or open-source project behind each. Use GLPI's Assets module or Wazuh's Syscollector inventory as the source, then check that the export covers every in-scope host and not only the ones an agent reached. Schedule the export and keep dated copies so the assessor can see change over time.

Acquisition contract clauses

Acquisition contracts for system components or services are the second examine object. Look for clauses that require the supplier to disclose the underlying technology, support alternatives, or document how a component fits a defined mix of technologies. Review these at each renewal and at each new procurement, and confirm that the clauses still match the platforms actually in use. Contracts do not prove the mix exists, so pair them with the inventory export.

System design documents with diversity rationale

Design documentation should state which technologies the organization chose for each defined component, and why those choices reduce the chance that one exploited vulnerability reaches every component. Record the rationale in the system design record and update it at each significant change, such as a new database engine, a replaced operating system family or a shift to a different identity service. Ask the design owner to sign off on each revision so the record shows who accepted the trade-offs.

Configuration baselines

Configuration settings are the fourth examine object. Keep baseline configuration records for each technology in the mix, showing the versions and settings the organization approved. The purpose is to show that the diverse components are actually configured as documented and not left at vendor defaults that make them look alike. Compare baselines against the live inventory at each scheduled review and file the drift report, even when no drift is found.

Change records for new components

Change tickets show whether new components keep the defined mix. Each change that adds or replaces a component should record the technology chosen, the design check that confirmed it still fits the defined mix, and the approver. Review a sample of recent changes before each assessment and flag any change that introduced a technology already dominant in the system. These records connect the design rationale to what was actually built.

Assessment interview notes

SP 800-53A also uses interviews, so the people who choose and approve components must be able to explain the mix. Record who owns the diversity decision, how often the owner reviews it, and how exceptions are approved and expired. Keep these notes with the design records. Confirm the owner can describe the defined mix from memory, because an assessor will ask.

What meeting SC-29 costs in money and effort

This table breaks the cost of an SC-29 heterogeneity program into components, showing who is paid, whether each cost is one-time or recurring, and what drives it up or down. NIST does not estimate compliance costs, so use the rows to structure quote requests rather than to budget. The main takeaway is that open-source licenses remove software spend, but design, diversity management and evidence work remain engineering and operating effort.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Engineering time to define components and design diversity	Internal architects or an implementation partner for scoping and design	One-time, revisited at major architecture changes	Number of defined components and how many technology stacks are in scope
Tooling for component inventory	Open-source platforms such as GLPI or Wazuh carry no license fee, but deployment and hosting are paid	Mostly one-time setup, then recurring operation	Number of asset classes, integration with existing CMDB, and whether inventory is automated
Running mixed technologies (training, patching, integration testing)	Internal operations staff, and partners if outsourced	Recurring	Number of distinct technology stacks, separate patch streams and staff cross-skilling
Separate patch and vulnerability streams	Internal security and platform teams	Recurring	Count of vendors or distributions, and how often each releases security updates
Evidence upkeep (design records, configuration exports, change history)	Internal compliance or GRC staff	Recurring	Frequency of assessments and how well evidence is generated automatically
External review of the diversity design	Independent security architects or assessors engaged by the organization	Periodic, often one-time per design change	Scope complexity, whether the design is documented clearly, and how many reviews are requested
Auditor or assessor sampling and testing	The organization pays its independent assessor, not DeployOpen	Recurring per assessment cycle	Number of components sampled and quality of the examine objects such as acquisition contracts
Contract flexibility with vendors	Procurement and legal teams	One-time negotiation, recurring if terms change	Ability to require diverse suppliers, support for mixed versions and exit terms

Who does what for SC-29: your team, a partner and the auditor

Your organization owns SC-29. Only you can decide which system components the control applies to, what counts as a diverse set of technologies for your environment, and which products, operating systems, platforms or vendors you accept as part of that set. Those decisions carry the risk, so they must be recorded in your own governance and risk documents, not delegated to a vendor or consultant.

Defined components: Set the organization-defined parameter for the components in scope and document why others are excluded.
Diversity decision: Choose the technologies that provide diversity and record the reasoning, including the single points of failure you accepted.
Acquisition choices: Write diversity expectations into procurement requirements and contracts, since the examine objects include acquisition contracts.
Ownership and review: Assign an accountable owner and review the decision when the architecture or vendor landscape changes.
Tailoring decision: SC-29 is not in any SP 800-53B baseline, so confirm with your authorizing official or compliance lead whether it is selected at all.

Before engaging anyone, confirm that your own policy and architecture documents already state who makes the diversity decision.

Open-source tools that produce SC-29 inventory evidence

SC-29 asks an organization to show which technologies its components use, so it can judge whether one flaw could reach everything. Two open-source platforms can supply the raw inventory that feeds that judgment. Neither one makes the diversity decision, and each needs to be checked against the environment it will run in.

GLPI asset records

GLPI's Assets module holds computers, network equipment, software, monitors, printers, phones and racks as managed records. Entries can be typed in by hand or pushed automatically by the GLPI Agent through native inventory, which GLPI has included since version 10. For SC-29, an assessor will look for a list of technologies deployed in the system. Confirm that the asset types, fields and export format you need for that list are available in your GLPI setup, and that someone reviews the records for gaps.

Wazuh Syscollector inventory

The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups from each endpoint. It stores that data in the Wazuh indexer, where the dashboard can show inventory views and reports. These records show what is actually running, which is often different from what a register says. Confirm agent coverage across your endpoints and servers before treating the output as a complete technology list.

Reconciling the two inventories

GLPI tends to hold the approved, owned record of each asset, while Wazuh reports what is installed and listening on each host. Comparing them can expose unregistered systems and software that were never added to the asset register. An assessor reviewing SC-29 will want to see that the technology list matches the system as it runs. Document the reconciliation schedule, the owner of discrepancies and how exceptions are closed.

Inventory is not the diversity decision

Neither tool decides which technologies should differ across components, and neither records why. The diversity rationale, the selected technology choices and any accepted concentration risk are organizational artifacts. They belong in the system design documentation and acquisition records that the SC-29 examine methods also review. Plan to write these artifacts yourself, and use the tool exports only as supporting evidence.

Confirming tool fit

Before you rely on either tool, confirm its licensing terms, deployment model and capacity for your environment. GLPI is licensed under GPL-3.0-or-later and Wazuh's components are under GPL-2.0-only, so check how those terms apply to your use and any modifications. Also confirm which asset types, operating systems and network devices each tool can see in your estate. Record the results in your own evidence file.

Where SC-29 programs usually fall short and how to close the gap

The most common SC-29 gap is a control selected without a defined component list. Teams describe their platform as diverse, but nobody has named which system components the requirement covers, so an assessor has nothing to test. Start by writing down the components in scope, such as operating systems, hypervisors, databases, identity services and network devices, and by setting the organization-defined parameter that states how diversity will be judged. The related gap is an inventory that is out of date or kept by hand. Generate the list from the running systems, for example from a self-hosted asset tool or an endpoint agent such as the Wazuh system inventory module, then reconcile the export against the documented list at every review cycle. These steps do not depend on any particular product.

Diversity is often claimed in architecture diagrams but never shows up in configuration. An assessor applying the examine method will compare the stated design with system configuration settings, so confirm that the technologies named in the design run where the design says they run, such as different operating system families, separate database engines or independent authentication paths for critical functions. Where two components share one vendor stack, record why that is acceptable. The acquisition gap is a set of contracts that lock in one vendor stack. Review the acquisition contracts for system components and services and ask whether renewals, support terms or licensing would force the same technology everywhere. Add language that lets the organization choose alternative technologies for defined components, and confirm with procurement how that language affects pricing. Link these decisions to the supply chain controls in SR-3 so the evidence sits in one place.

SC-29 heterogeneity questions buyers ask before hiring help

Does SC-29 apply to my system if it is in no SP 800-53B baseline?

Not automatically. SP 800-53B does not assign SC-29 to the low, moderate, high or privacy baseline, so it applies only when your organization selects it through tailoring or an overlay, or when a contract, authorizing official or regulator requires it. Appendix C of SP 800-53 Rev. 5 lists it as implemented by the organization and marks it as assurance-related. Start by reading your system's current baseline and any overlay or contract clause that names SC-29. If it is not selected and no one requires it, the control stays out of scope, though your risk assessment may still justify it for specific components.

How much effort does SC-29 add to an existing SP 800-53 program?

The effort depends on how many components you must diversify and how much of the technology estate is already mixed. The control requires a diverse set of information technologies for defined system components, so the first task is to define those components through your own organization-defined parameter. Effort rises with the number of platforms in scope, the number of acquisition contracts that must be reviewed, and how much design documentation must be written. Ask any partner to quote from a written scope that lists the components, the systems and the documents to produce. DeployOpen plans and documents work like this under fixed-scope engagements, with the scope agreed in writing before work starts.

How long does it take to implement SC-29?

No standard duration applies, and no supplied figure sets one. The timeline is driven by the number of defined components, whether the environment already runs more than one technology family for the same function, the lead time for procuring or approving alternative products, and how long your architecture review and change control take. Teams that already keep documented technology choices for key components will move faster than teams that must first build an inventory. Ask a partner to break the timeline into defining components, designing diversity, procurement, deployment, and collecting evidence, and to state which steps depend on your own approvals.

What does the SC-29 work need from our own team?

Your team must own the decisions. Someone with authority over architecture must define which components the control covers, approve the technologies chosen for each, and accept the residual risk of any single-vendor component that remains. Your acquisition or procurement team must supply contract documents, because the examine methods in SP 800-53A include acquisition contracts for system components or services. Your operations team must provide current configuration settings and an accurate list of technologies deployed in the system. Plan for these people to review drafts and sign off on design documentation.

Can our team implement SC-29 in-house?

Yes, if you have architecture ownership, an accurate asset inventory and staff who can document design decisions. The control is one determination statement in SP 800-53A Release 5.2.0, so the assessment burden is modest, but the design work is real. Open-source inventory tools such as GLPI can record the technologies in use across assets, and Wazuh's Syscollector module can collect installed software and operating system details from endpoints, which together give you the list of technologies an assessor will examine. Consider a partner if you lack engineers who can evaluate diverse technologies or if the inventory is incomplete. A partner's role is to prepare systems and evidence, not to decide your risk posture.

What should a partner do for SC-29 and what should it never do for the audit?

A partner should help define the components, document the design, collect the examine evidence, configure inventory tools, and prepare the evidence package for your assessor. It should write its work in your own words and keep your organization as the owner of the control. A partner should not issue an assessment report, attest that the control is satisfied, or present itself as the independent assessor. Only an independent assessor or authorizing body can make that determination. Ask for the deliverables in writing, including which documents you will own and which artifacts the assessor will receive.

Does a FedRAMP Class B, C or D system have to include SC-29?

No. The FedRAMP Rev5 baselines in the 2026 consolidated rules do not require SC-29 at Class B, C or D. That means the control is not a default requirement for those classes, but a specific agency, contract or risk decision can still add it. Confirm the current FedRAMP requirement in the Rev5 reference and in your authorization package, because requirements can change. If your agency customer asks for SC-29 in writing, treat it as a tailoring decision and scope the work from that written request.

How DeployOpen scopes and prepares SC-29 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the technology diversity SC-29 asks for can be defined, deployed and evidenced in your environment. We prepare the systems and records an assessor will examine, while your organization owns the control decision and an independent assessor reaches the conclusion.

How we scope

We confirm which system components SC-29 applies to, based on your organization-defined parameter and tailoring decisions.
We agree in writing which technologies, layers and vendors fall inside the diversity decision and which sit outside it.
Engagements are fixed-scope, with deliverables and timelines agreed before work starts, and ongoing support available as a retainer.

How we build

We document the technology inventory for in-scope components, using open-source asset and inventory tooling where it fits your environment.
We configure and integrate the chosen platforms in your cloud accounts, data centers or air-gapped networks, recording design decisions along the way.
We test the diversity choices against the examine and test methods in SP 800-53A, so gaps surface before the assessor arrives.

How we hand over

We deliver the design documentation, configuration baselines and inventory exports that show the deployed technologies and their settings.
We map the evidence to SC-29 and the related controls named in the catalog, so your assessor can trace each claim to a artifact.
We confirm with you which acquisition contracts and third-party records your team must supply, since those sit outside our build work.

How we support

We can keep the inventory and configuration records current as components are upgraded, replaced or added to the system.
We can rerun checks against the SC-29 procedures after material changes, under a retainer agreed in writing.
We prepare material for your assessor and remain available to answer questions about our work, while the assessment decision stays with the independent assessor.