Official intent
Keep a flexible technology stack so you can adopt or swap capabilities without introducing security regressions. The official source remains authoritative.
Read the official campaign ↗Lock-in is a risk multiplier. A flexible stack — built on documented baselines, standard interfaces, and portable data — lets you replace a weak or end-of-life component without re-architecting the business. The goal is not novelty; it is the ability to change safely when a product, threat, or requirement changes.
Who this applies to: Most relevant to organizations that run more than a handful of business systems, or that expect an acquisition, a cloud migration, or a CUI-boundary change within the next two years.
Why it matters
When swapping a tool means a painful, risky project, teams delay upgrades and keep insecure components running. Standard configurations and clean integration points turn a forced change (a breach, an acquisition, an end-of-support date) from an emergency into a planned move — and stop each change from quietly weakening your security baseline.
Risks this reduces
- Security regressions introduced quietly by each tool swap or integration
- Insecure components kept running because replacing them is too painful
- Undocumented one-off configurations that nobody can reproduce or verify
- Data trapped in a format only one vendor can read
Who owns it
IT leader
Architecture lead, Application owners, MSP
Medium
Medium
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: IT-02 — Asset inventory, IT-03 — Technical debt reduction
- One central identity provider that new applications can authenticate against
- An agreed definition of what a documented baseline contains
- A named architecture owner who reviews new tools before adoption
Action timeline
- Identify systems with no documented configuration
- Flag any single points of hard lock-in
- Write down the baseline configuration for the one system you would least like to rebuild from memory
- List every application that authenticates with local accounts instead of the central identity provider
- Document baseline configurations for core systems
- Standardize authentication on the central identity provider
- Map integrations and replace brittle custom links with standard interfaces
- Confirm critical data can be exported in an open format
- Adopt a secure-configuration checklist for new tools
- Review one planned change against the baseline before rollout
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- Document baseline, hardened configurations for core systems so “known good” is written down.
- Centralize authentication and authorization on one identity provider instead of per-app logins.
- Prefer standard, well-supported interfaces over bespoke integrations that are hard to unwind.
- Keep data portable — verify you can export critical data in an open, documented format.
- Put new tools through a secure-configuration checklist so every addition inherits the baseline.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
Configurations are tribal knowledge and each integration is bespoke.
Is there anything at all — a tool, a document, a person who owns it? - Documented
Baseline configurations exist in writing for core systems, with an owner for each.
Is the intent written down, with a named owner and a scope? - Configured
Core systems are built to the documented baseline and authenticate against the central identity provider.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
Integrations use standard interfaces, critical data is exportable, and the baseline is applied across the estate.
Does it cover everything in scope, with the exceptions written down? - Measured
Drift between documented and deployed configuration is detected and reported, and export tests are recorded.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
The baseline is owned and reviewed on a cadence, and architecture decisions record their portability implications.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not deployed.
- Pick a core system and confirm its documented baseline matches what is actually deployed.
- Verify a critical dataset can be exported and re-imported without loss.
- Confirm new applications authenticate through the central identity provider, not local accounts.
Evidence to retain
Secure-configuration standard and change checklist
Baseline configuration documents for core systems
Records of changes tested against the baseline
Data-export test result and identity-integration review
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| Baseline coverage | Core systems with a current documented baseline ÷ core systems. | 100% of systems classified as core. |
| Central authentication | Applications authenticating through the central identity provider ÷ all business applications. | Rising toward full coverage; local-account exceptions dated. |
| Configuration drift | Systems where deployed configuration differs from the documented baseline. | Investigated within the agreed window; zero unexplained. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
Baselines that exist as tribal knowledge instead of documents, “integration” that is one fragile custom script, and data trapped in a format only one vendor can read. Flexibility claimed but never tested is not flexibility.
Two sized paths
Skip the architecture programme. Write a one-page baseline for each of your three or four core systems, get everything onto single sign-on, and prove once a year that you can export your critical data. That is the whole practice at small scale, and it is genuinely valuable.
Express baselines as code so drift is detectable and remediation is repeatable, and require an exit path — data export, standard interfaces, identity federation — as a condition of adopting any new platform. Test portability rather than asserting it.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
Standardization changes touch authentication and integration paths, which is where outages come from. Run new tools through the secure-configuration checklist before rollout, and change one dimension at a time — identity, then integration, then data.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The same reasoning carries to the inherited CMMC practice.
What this does not claim: Supports the requirement; it does not satisfy it on its own and does not establish an assessment outcome. Scope, implementation quality, and evidence decide that.
Why: The configuration-management outcome covers establishing and maintaining secure baselines.
What this does not claim: The CSF describes outcomes, not testable controls.
Why: Secure configuration processes for enterprise assets and software describe the baseline half of this practice.
What this does not claim: CIS has no equivalent to the portability and vendor-flexibility half of the practice.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.4.2Security configuration enforcementOperational supportModerate
Why: Documented, portable configuration baselines — the practice's mechanism for swapping products without security regressions — are what keep established security settings maintainable when the stack changes underneath them.
What this does not claim: The requirement is to establish and enforce the settings, and the practice does neither: it makes an existing configuration standard survivable through product change. Contributes to the requirement's durability rather than its substance, and the enforcement tooling and drift measurement remain separate work.
Review status: Technical review complete.
Open the 3.4.2 page →NIST SP 800-171 Rev. 3
03.04.02Configuration SettingsPartial implementation supportModerate
Why: The practice's documented, portable baselines — written per core system and inherited by new tools through a secure-configuration checklist — are the establish-and-document half of this requirement, and its drift detection is the signal that deployed settings still match documented ones.
What this does not claim: May partially address the requirement: the practice does not itself select organization-defined settings against a most-restrictive-mode test, and its portability emphasis is not this requirement's concern. Fleet-wide enforcement and a maintained deviation register are separate work that the baseline documents enable but do not perform.
Review status: Pending NIST SME review.
Open the 03.04.02 page →03.16.01Security Engineering PrinciplesContextual relationshipModerate
Why: A deliberately modular, swappable technology stack embodies several of the engineering principles this requirement draws on — modularity, loose coupling, reduced concentration on any single vendor — so the practice shapes the architecture the requirement evaluates.
What this does not claim: The practice informs the requirement rather than implementing it: modularity is one principle among many, and a swappable stack can still be assembled without layered defense, least privilege, or a minimized attack surface. Treat the relationship as architectural context, not coverage.
Review status: Pending NIST SME review.
Open the 03.16.01 page →03.16.03External System ServicesPartial implementation supportModerate
Why: A stack built for swap forces deliberate external-service management: capabilities are chosen against defined criteria, adopted with exit paths, and replaceable when a provider's security posture degrades — which supplies the selection discipline and the leverage that this requirement's provider obligations depend on.
What this does not claim: May partially address the requirement: swap-ability creates the conditions for imposing security requirements on providers, but the imposing itself — contractual obligations, documented oversight, defined user roles per service — is separate work the practice does not perform. A replaceable service with no security terms in its agreement leaves the requirement's core untouched.
Review status: Pending NIST SME review.
Open the 03.16.03 page →Review status
| Technical review | Reviewed |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.0 |