Config Drift Checker

Baseline name:

Use a short name that makes the drift evidence traceable.

Intended config:

Paste the approved state. Comment and blank lines are ignored.

Observed config:

Paste the observed state from the device, service, deployment, or runtime export.

Key matching:

Choose how key names are matched between intended and observed inputs.

Value handling:

Use exact mode for final audit evidence; collapse whitespace for noisy operational captures.

Priority keys:

Mark controls that should be reviewed first when missing, changed, or unexpectedly present.

{{ error }}

Ignored keys:

Leave blank for a full comparison. Example: last_seen, generated_at, session_*.

Include unchanged rows

Adds aligned keys to the finding ledger for full handoff evidence. Default keeps the ledger focused on drift.

Measure	Value	Evidence	Action	Copy
{{ row.measure }}	{{ row.value }}	{{ row.evidence }}	{{ row.action }}

Key	Drift type	Severity	Intended	Observed	Evidence	Copy
No actionable drift rows The current comparison is aligned, ignored, or limited to unchanged keys.
{{ row.key }}	{{ row.driftType }}	{{ row.severity }}	{{ row.intended }}	{{ row.observed }}	{{ row.evidence }}

Priority	Key	Drift type	Owner action	Evidence	Copy
No remediation queue rows Changed, missing, or extra keys will appear here when the comparison finds actionable drift.
{{ row.priority }}	{{ row.key }}	{{ row.driftType }}	{{ row.ownerAction }}	{{ row.evidence }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Configuration drift is the gap between the state an environment is supposed to have and the state it has now. It appears after emergency fixes, console changes, partial rollbacks, vendor defaults, missed automation runs, or copied settings that look close enough until a reviewer compares them line by line. Small differences can matter because configuration controls often decide who can connect, where logs go, which services are exposed, and whether a recovery playbook will behave as expected.

A useful drift review starts by naming the source of truth. The baseline is the approved reference state, usually drawn from a build standard, change record, infrastructure template, hardened image, device profile, or service policy. The observed state is a current capture from the system being checked. When those two views are flattened into named settings, each difference can be discussed as evidence instead of as a vague feeling that the system is "not quite right."

Key-value comparison fits many operational captures because it reduces noisy exports into one setting per line. Network device snippets, environment files, service toggles, application flags, and admin-console exports often contain the same basic shape: a key, a separator, and a value. That shape is not as rich as a full parser for every vendor syntax, but it gives reviewers a practical way to find changed values, missing baseline controls, unexpected live settings, and intentionally ignored volatile fields before they enter a ticket or change window.

Common configuration drift cases
Comparison case	Typical meaning	Review caution
Same key, different value	A setting changed after the baseline was approved.	Confirm whether the live value was authorized, temporary, or a change that should be rolled back.
Baseline key missing from the observed state	A required setting may not be applied, may be hidden by a profile, or may use a different name in the export.	Check the capture method and naming convention before assuming the control is absent.
Observed key absent from the baseline	The live system includes an extra setting, generated field, default, or unrecorded addition.	Decide whether to remove it, approve it, or add it to the baseline with a reason.
Volatile key intentionally ignored	A timestamp, session value, generated ID, or last-seen field is being kept out of the action queue.	Ignored evidence still needs a reason, especially in regulated or security-sensitive environments.

Drift is not automatically bad. A missing setting can be a real control failure, but it can also be a capture problem. An extra setting can be a risky shadow change, a vendor default, or a new approved value that never made it back into the baseline. Changed values need the same discipline: compare the evidence, check the change record, and decide whether the live system or the baseline should be corrected.

The biggest mistake is treating a text comparison as proof that the environment is safe. A key-value check cannot see inherited policy, hidden defaults, secrets stored elsewhere, vendor-specific merge behavior, or whether the baseline itself is still the right standard. It is best used as a fast, reviewable drift screen that feeds a change-control or remediation process.

How to Use This Tool:

Start with a trusted baseline and a fresh observed capture. The checker works best when each setting is on its own line and repeat comparisons use the same capture command, export scope, matching mode, and ignore rules.

Enter a Baseline name that identifies the source of truth, such as an environment, device group, policy version, or change ticket.
Paste or browse for the Intended config and Observed config. Use key=value or key: value lines where possible; blank lines and comment lines are ignored.
Choose Key matching. Use strict keys for final evidence when case can matter. Use case-insensitive matching for noisy exports where mixed-case key names represent the same setting.
Choose Value handling. Collapse whitespace reduces false positives from copied command output. Exact trimmed values is safer when spaces inside a value carry meaning, such as banners, templates, command strings, or access rules.
List Priority keys for controls that should rise in the queue when they change, disappear, or appear unexpectedly. Exact keys, comma-separated lists, new lines, wildcards, and regular-expression patterns are accepted.
Use Ignored keys only for approved volatile fields such as timestamps, generated IDs, session markers, or last-seen values. Keep the ignore list short enough to defend in review because ignored rows stay out of the remediation queue.
Open Drift Finding Ledger for row-level evidence and Remediation Queue for the ordered action list. Turn on Include unchanged rows when you need a fuller comparison ledger.
Resolve validation errors and parser warnings before sharing evidence. Missing input, invalid regular expressions, duplicate keys, and lines without separators can change the meaning of the result.

Interpreting Results:

Read the summary and Drift Snapshot first. Actionable drift counts changed, missing, and extra rows after ignored rows are removed from the action queue. Intended compliance uses intended keys as the denominator and counts only keys classified as unchanged, so extra observed keys are tracked as drift without directly reducing that percentage.

The Drift risk score is a local triage score, not a formal risk rating. Priority-key findings receive higher weights so they sort ahead of routine differences. A low score only means this comparison found few weighted differences under the current settings; it does not prove that the baseline is complete, the capture is comprehensive, or ignored values are safe.

Config drift result cues
Output cue	What it means	What to verify
`Priority drift detected`	At least one priority key is changed, missing, or extra.	Review Critical and High rows before routine clean-up items.
`Config drift detected`	Actionable differences exist, but no priority-key Critical finding is present.	Check whether each difference is an approved exception, a stale baseline, or a real remediation item.
`Baseline aligned`	No actionable drift remains under the current matching and ignore settings.	Confirm that the baseline and observed capture cover the same scope.
`Parser warnings`	Some lines were compared as presence-only keys or repeated as value sets.	Normalize the source text or inspect duplicate-key semantics before applying changes.

The chart tab gives a quick count-and-score view by drift type. Use it for review meetings or handoff summaries, then return to the ledger for exact keys, values, line evidence, and row-level copy actions. The JSON export is most useful when the comparison needs to be attached to a ticket, archived with a change record, or passed into another workflow.

Be careful with ignored keys. Ignoring a volatile field can keep the queue usable, but a broad pattern can hide evidence that should be reviewed. Treat every ignore rule as an explicit exception, not as a way to make the result look clean.

Technical Details:

Configuration drift checking is a set comparison problem. One record set represents the approved baseline, the other represents the observed state, and every normalized key is classified by presence and value equality. The comparison is intentionally simple enough to audit: a setting is either present on both sides with matching values, present on both sides with different values, present only in the baseline, present only in the observed state, or intentionally ignored by a matching rule.

Text normalization matters because many configuration captures are made for humans rather than machines. A copied terminal session may have uneven spacing, a service export may add a leading export, and a portal may use : where a file uses =. Blank lines and common comment prefixes are ignored, one pair of wrapping quotes around values is stripped, and internal whitespace can be collapsed when the selected value rule allows it.

Rule Core:

The classification order gives ignore patterns first claim over a key, then assigns missing, extra, changed, or unchanged status from the two record sets. Priority patterns do not change the finding type; they raise the severity and queue order for changed, missing, or extra rows.

Config drift finding assignment rules
Ordered condition	Finding type	Action meaning
Key matches an ignored pattern	`Ignored`	Keep evidence visible but remove it from the remediation queue.
Key exists in intended config only	`Missing`	Restore the setting, fix the capture, or update the baseline if the absence is approved.
Key exists in observed config only	`Extra`	Remove the setting or document it as an approved addition.
Key exists on both sides and normalized value sets differ	`Changed`	Reconcile the live value with the intended value or approve an exception.
Key exists on both sides and normalized value sets match	`Unchanged`	No direct remediation is needed for that key.

Parsing and Matching Notes:

Configuration parsing and matching behavior
Input pattern	How it is compared	Practical effect
`key=value` or `key: value`	The text before the separator becomes the key and the text after it becomes the value.	Best fit for final review evidence.
`export key=value`	The leading export marker is removed before comparison.	Environment-style exports can be compared without manual cleanup.
Line without `=` or `:`	The whole line becomes a presence-only key with value `present`.	Useful for simple flags, but parser warnings should be reviewed.
Repeated key	Distinct values are compared as a sorted value set.	Supports repeated statements such as multiple servers, while still flagging duplicate-key warnings.
Wildcard or regular-expression pattern	The pattern is tested against the normalized key name.	Priority and ignore lists can cover groups such as `aaa*` or generated session fields.

Formula Core:

Compliance uses the intended record count as the denominator. The numerator is the number of intended keys that remain classified as unchanged after matching and ignore rules are applied. Risk score is the sum of severity weights for actionable rows only, which means ignored and unchanged rows carry a weight of zero.

\begin{array}{lcl} intended compliance percent & = & \frac{unchanged intended keys}{total intended keys} \times 100 \\ drift risk score & = & \sum_{actionable finding}^{all actionable findings} severity weight \end{array}

Severity weights are additive and deliberately small. They make the queue sortable; they do not replace engineering judgment, system criticality, exploitability, or business impact.

Config drift severity rules
Finding	Priority key?	Severity	Weight
`Changed` or `Missing`	Yes	`Critical`	`5`
`Extra`	Yes	`High`	`3`
`Missing`	No	`High`	`3`
`Changed`	No	`Medium`	`2`
`Extra`	No	`Low`	`1`
`Ignored` or `Unchanged`	Either	`Info` or `None`	`0`

For repeatable drift reviews, keep the same capture command, matching mode, value rule, priority list, and ignore list between runs. Changing those settings can be valid, but it also changes the comparison boundary and can make trend claims harder to defend.

Limitations and Privacy Notes:

Configuration text can contain secrets, internal addresses, customer identifiers, hostnames, and operational details. Treat pasted inputs, loaded files, copied rows, chart exports, tables, and JSON downloads as sensitive evidence. If the current page URL contains pasted values, do not share it outside the approved review channel.

Files larger than 1 MiB are rejected so the browser-side comparison stays manageable.
Nested formats need to be flattened before comparison. The checker does not understand vendor-specific blocks, inherited policy, YAML hierarchy, JSON paths, or platform defaults unless they appear as comparable lines.
A clean result means the two supplied texts align under the selected rules. It does not prove that the observed capture is complete or that the baseline is the right security standard.
Ignore patterns and case-insensitive matching can reduce noise, but they can also hide meaningful differences when used too broadly.

Worked Examples:

If the baseline contains snmp=enabled and the observed capture contains snmp=disabled, the row is Changed. When snmp matches a priority pattern, the remediation queue raises it as Critical and recommends reconciliation or an approved exception.

If aaa_mode=tacacs appears only in the intended config, the row is Missing. Authentication and access-control keys are common priority candidates, so that missing row should be reviewed before low-risk extras such as a banner or generated timestamp.

A copied CLI capture may show logging_buffered = 64000 on one side and logging_buffered=64000 on the other. With Collapse whitespace selected, those values align. With Exact trimmed values, spacing inside the value is preserved, which is safer for settings where whitespace changes behavior.

A repeated setting such as two dns lines is compared as a value set. That can be correct for multi-server settings, but the duplicate warning should still be checked because repeated lines sometimes mean a copied block, merge artifact, or accidental override.

FAQ:

Can this compare full YAML, JSON, or vendor configs?

Only after they are flattened into comparable lines. The comparison is built around key-value or line-presence records, so nested structure and vendor-specific inheritance need separate handling.

Why is an extra observed key treated as drift?

An extra key means the live state contains something absent from the baseline. It may be harmless or approved, but it still needs review because it changes the difference between intended and observed state.

Why can ignored keys affect intended compliance?

The compliance percentage counts keys classified as unchanged. An ignored intended key is kept as ignored evidence instead of unchanged evidence, so broad ignore rules can change the percentage as well as the queue.

When should case-insensitive matching be used?

Use it for exports where key names are operationally the same despite mixed case. Keep strict matching when case can change meaning or when the comparison is final audit evidence.

Why did a line without a separator appear as present?

A non-empty line without = or : becomes a line-presence key with value present. Review the warning and normalize the line if it was meant to carry a normal value.

Glossary:

Baseline: The approved intended configuration used as the comparison target.
Observed state: The current live, exported, or post-change configuration being compared with the baseline.
Configuration drift: A difference between the intended configuration and the current observed configuration.
Priority key: A key or pattern that raises the severity of changed, missing, or extra drift.
Ignored key: A key or pattern kept as evidence but removed from the actionable queue.
Line-presence key: A non-empty line without a separator, compared as present rather than as a normal key-value record.

References:

NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems, National Institute of Standards and Technology.
NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, National Institute of Standards and Technology.
Detect unmanaged configuration changes to stacks and resources with drift detection, AWS CloudFormation User Guide.
How AWS Config works, AWS Config Developer Guide.