GLBA Safeguards and FFIEC: endpoint monitoring evidence

Which rule applies to you

The control substance overlaps almost completely. The citation does not. A vendor answering a questionnaire with FTC Safeguards paragraph numbers to a credit union examiner is answering the wrong question, and the reverse is equally true.

One note on examination tooling. The FFIEC Cybersecurity Assessment Tool was retired, and institutions that had standardized on it have been directed toward other frameworks, commonly the NIST Cybersecurity Framework. Confirm what your own regulator currently expects before mapping controls to a retired instrument.

314.4(c)(8): monitoring and logging of authorized user activity

The requirement has two halves. Log what authorized users do, and detect unauthorized access to or use of customer information.

Authorized user activity

Every command executed against an endpoint, whether ad hoc or from the script repository, is scored against 18 risk indicators before it runs and recorded with the risk score, the matched indicators, the user identity, the target agent, a hash of the command and the execution decision. Commands scoring 60 or above generate elevated warning entries for review. Executions are rate limited to 30 per user per organization per hour.

Script creation and modification are logged with user identity, organization, timestamp and a SHA-256 content hash, which means a changed script is detectable rather than merely attributable.

On Linux, privilege escalation requires explicit operator authorization with a full audit trail. The agent never escalates silently.

Detecting unauthorized use

Ten always-on behavioral rules evaluate the kernel event stream on both Windows and Linux, covering mass file access, mass file rename to ransom extensions, ransom-note patterns, shadow copy and backup deletion, suspicious execution chains, reverse-shell heuristics, privilege escalation from non-interactive parents, unusual outbound traffic from system daemons, a crypto-miner heuristic, and a kill-chain rule that fires when two or more of the others occur within five minutes.

Detection runs against events the kernel emitted, not against a report from the process being evaluated. For an examiner asking how unauthorized use would be noticed, that distinction is the answer.

314.4(d): continuous monitoring, or testing on a schedule

The rule offers two paths. Implement continuous monitoring under 314.4(d)(1), or perform annual penetration testing plus vulnerability assessments at least every six months under 314.4(d)(2).

Where ET Ducky contributes to the (d)(2) path is on the vulnerability side of endpoint hygiene: patch policy across Windows and Linux from a single engine, staged ring rollouts, and post-patch verification drawn from the kernel event stream, meaning services back up, no crash loops, no baseline deviation and no behavioral rule firings. A wave that regresses pauses and rolls back where the package manager supports it.

314.4(c)(5): multi-factor authentication

The rule requires multi-factor authentication for any individual accessing any information system, unless the qualified individual has approved a written equivalent or more secure control.

Identity is handled by Clerk, a SOC 2 Type II certified provider. ET Ducky does not store passwords or manage sessions. TOTP, SMS and passkey factors are available, session lifetime and idle timeout are configurable, and SAML or OIDC single sign-on is available on Clerk's enterprise plan. Enforcement is a setting the institution turns on, so the accurate examination answer is that the factor is available and that the institution has enabled it.

314.4(c)(3): encryption in transit and at rest

On a Local-First self-hosted instance, stored secrets are encrypted at the column level and the key ring is itself encrypted with an instance-generated certificate held outside the database, so a database dump alone is insufficient to decrypt them.

314.4(c)(6): secure disposal

The rule requires disposal of customer information no later than two years after the last date it was used, unless retention is otherwise required or targeted disposal is not reasonably feasible.

Retention is configured per agent, at 14 days by default and extending to 90, 365 or 730 days. Purging runs as a scheduled background service and deletes permanently, with no archival copy unless the customer configures one at the infrastructure level. The maximum tier sits inside the two-year boundary.

One exception belongs in the disposal narrative. An organization placed under a legal or security hold is skipped by the purge so the evidence trail survives an investigation. Automatic holds expire 365 days after placement. Manual holds remain until an administrator releases them. Both can be released early. An institution documenting a disposal schedule should describe the hold behavior rather than describe the tier as a guaranteed maximum age.

314.4(h): incident response

On a detection at or above the configured confidence threshold, the agent applies network isolation to the implicated endpoint automatically and a ticket is opened in the connected ticketing system carrying the alert evidence and a note that isolation was applied.

Release requires dual approval. An authenticated dashboard request is necessary but not sufficient. A person at the device must independently approve, either by entering a single-use HMAC-TOTP code or by approving an on-device prompt. Containment and release are therefore separately attributable in the incident record, which is what a written response plan needs to demonstrate.

Note the boundary. A written incident response plan under 314.4(h) covers roles, external communication, regulatory notification and post-incident revision. The product supplies the technical record inside it.

314.4(f): overseeing ET Ducky as a service provider

The rule requires an institution to select and retain service providers capable of maintaining appropriate safeguards, and to contract for those safeguards. Turning that lens on ET Ducky, here is what a due diligence file can and cannot contain today.

What the file can contain: the security whitepaper, the security posture page including the sub-processor list and responsible disclosure policy, a written questionnaire response, and the sub-processor attestations, all of which are current.

For an institution whose vendor management policy requires an attested provider, the Local-First self-hosted deployment is the path that changes the analysis. The same server codebase runs on the institution's own infrastructure, cloud-only surfaces are removed from the application model at startup rather than merely blocked, no vendor-side secrets ship to customer infrastructure, and endpoint telemetry lands only in the institution's own PostgreSQL. The documented egress list is the complete set of outbound connections.

What this does not cover

No endpoint agent supplies a written risk assessment under 314.4(b), a qualified individual under 314.4(a), workforce training under 314.4(e), the annual board report under 314.4(i), or the breach notification obligation under 314.5. Those are program obligations.

Related: cyber insurance endpoint control questions and public sector procurement facts.