AU-10 Non-repudiation: requirements and evidence

What AU-10 non-repudiation asks for and why it is hard

When an assessor or a contract asks whether actions in your system can be proven to a specific person or process, they are asking about AU-10. The control requires the system to provide irrefutable evidence that an individual, or a process acting for that individual, performed a defined action, such as creating information, sending or receiving a message, or approving a document. The organization owns this requirement and decides which actions matter. An implementation partner can configure the platform and collect the evidence, but only the organization can state which actions must be provable and to whom. Begin by listing those actions for each system in scope, because the control is tested against that list rather than against everything the system does.

The hard parts are identity binding and chain of custody. Identity binding means the evidence ties an action to one authenticated identity, not to a shared service account, a reused password or a session that anyone could have taken over. Chain of custody means the proof stays intact from the moment of the action until an assessor examines it, which depends on protected storage, signed or tamper-evident records and a clear record of who could touch them. AU-10 is often confused with ordinary logging covered by AU-2, AU-3 and AU-9. A log that records a user name is useful, but it is weaker than non-repudiation if the account was shared, the clock was unreliable or an administrator could alter the entry. Confirm with your platform team whether approvals and document actions are signed with keys tied to a named identity, and whether the signing material is managed through a documented certificate authority such as the one in FreeIPA.

AU-10 is selected in the high security control baseline in SP 800-53B Release 5.2.0, and none of its four current enhancements are selected in any baseline, so a moderate system does not inherit the requirement by default. It is not in the privacy baseline. Check your system's impact categorization before deciding whether the control applies, and ask your assessor to confirm whether the organization has chosen to implement it voluntarily or because a contract requires it. Scope the work early, because identity binding and key management often touch identity, certificate and configuration controls, which will need their own evidence.

Which systems and actions AU-10 applies to

AU-10 is not applied uniformly. Its scope depends on the impact level of the system, the kinds of actions that carry legal or financial weight, and who or what performs those actions. The cards below cover the decisions that change the work most, starting with where the high baseline applies and ending with third parties whose actions must be provable.

Systems categorized at high impact

SP 800-53B selects AU-10 for the high security control baseline, so it is required by default only where the system's security categorization is high. Moderate and low systems do not inherit it from the baseline. Check the FIPS 199 categorization in the system security plan first, because a system categorized high for integrity or availability may pull AU-10 into scope even if confidentiality impact is lower. Confirm this with the authorizing official or the program's compliance lead, not only the engineering team. Systems that move to moderate after tailoring still need a documented reason if they keep the control.

Approvals and sent notices

Approvals, contract acceptances, change authorizations and formal notices are the actions most often challenged later. AU-10 asks whether the system can show that a specific person performed the approval and that the content approved is the content recorded. For each workflow, list the actions that create legal or financial consequence, such as release approvals, payment releases and customer notifications, and confirm that the audit record captures the actor, the object and the time. Ask whether approval records can be altered by the same administrators who approve.

Signed transactions and data changes

Where users sign transactions or submit data changes with digital signatures, the question is whether the signature and its signing key can be tied to one identified individual at the time of signing. Shared credentials, reused tokens and keys held in common vaults break that tie. Inventory the signing mechanisms in scope, record which key or certificate each one uses, and confirm how the key was issued and bound to the person. Key issuance and certificate management are typically governed under SC and IA controls, so AU-10 work depends on them.

Service accounts and automated processes

Service accounts, scheduled jobs and pipelines often act on behalf of people, for example by releasing batches or sending statements. AU-10 applies to these processes when their actions carry weight, and the record must still show which person or authorized process initiated them. Decide for each automated process who owns it, how its identity is issued, and whether a human approval precedes its consequential actions. Shared service accounts with no named owner are the most common gap an assessor will raise.

Third parties whose actions must be provable

When contractors, outsourced operators or partner organizations perform actions inside the system, the organization still needs to prove who did what. Identify which third-party users can approve, sign or send on the organization's behalf, and confirm that their identities are issued and recorded separately from employee identities. Contract terms should require that third parties use attributable credentials. Review how external identities are created and removed, because stale external accounts weaken any attribution claim.

Deciding which enhancements to adopt

The SP 800-53B baseline selects none of the four current AU-10 enhancements at any impact level, so no enhancement is required by baseline alone. The organization must decide which enhancements to adopt through its own risk assessment and tailoring, weighing the consequences of a disputed action against the cost of identity binding and chain of custody controls. Record each decision, with its rationale, in the system security plan so an assessor can trace it. Confirm the current enhancement list against the CPRT entry for AU-10 before finalizing.

How an assessor tests AU-10 and what they ask for

This table breaks the SP 800-53A assessment procedure for AU-10 into examine, interview and test methods, then pairs each object with the evidence an assessor typically requests and the gaps they most often find. Read it as a preparation checklist: each row is something the assessor will look at, and the single determination statement is what they ultimately decide. The main takeaway is that AU-10 is tested on configuration and mechanism evidence, not on a policy statement alone.

Assessment method	Assessment objects	Evidence requested	Common findings
Examine: policy	Audit and accountability policy	Approved policy text that addresses non-repudiation, owner, approval date and review record	Policy exists but never mentions non-repudiation or the high baseline scope
Examine: procedures	Procedures addressing non-repudiation	Documented steps for configuring signing, certificate issuance and verification of signed records	Procedures describe signing in general terms with no owner or verification step
Examine: plans	System security and privacy plans	Plan entries naming which actions are non-repudiable and the mechanism used for each	Plan states AU-10 as implemented without naming the mechanism or the actions covered
Examine: design	System design documentation	Architecture diagrams showing where signing keys, certificate authorities and verification points sit	Design omits the component that binds identity to the action
Examine: configuration	System configuration settings and associated documentation	Exported settings for signing, certificate profiles, key storage and logging of signed actions	Settings are default values that were never reviewed for the defined actions
Interview	System and network administrators	Walkthrough of how a signed action is verified and who can revoke or reissue keys	Administrators cannot explain how a signature is checked or who holds key material
Interview	System developers	Explanation of how application code creates, signs and records approvals or messages	Developers rely on shared service accounts, weakening identity binding
Test	Mechanisms implementing the non-repudiation capability	Test records showing a defined action is performed, signed, stored and then verified by a second party	Signature verifies only at creation, not after storage, or tests are not repeatable

How to implement AU-10 in order

This sequence turns AU-10 from a requirement into working evidence: defined actions, a chosen identity binding, protected records, a tested trace from record to person or process, and documented decisions an assessor can examine.

Define the actions that need non-repudiation
Start by listing the actions in your system where someone later needs to prove who did what, such as creating or approving records, sending messages, or changing high-impact settings. For each action, name the individuals, roles or processes involved and the assurance an investigator or counterparty would need. The output is a short register of covered actions with an owner for each. Confirm the list with business owners and the people who would rely on the evidence in a dispute, because AU-10 is scoped to defined actions rather than all logging. The step is done when every covered action maps to at least one actor and a named owner.
Select the identity binding method
Decide how each action is tied to one identity. Options include individual user credentials backed by strong authentication, X.509 certificates issued to people or services, and signing keys held by the actor. Certificates and keys need a certificate authority and lifecycle rules. FreeIPA includes an integrated certificate authority based on Dogtag, and OpenBao's PKI secrets engine can issue short-lived X.509 certificates to services. Confirm each product's current capabilities against its own documentation before you rely on them. The output is a binding decision record per action type, naming the identity source, the credential or key type and who issues it.
Design how records are protected and kept in custody
Define where the evidence of each action is stored, who can read it, and how it is kept unchanged. Record the custody chain: the system that captures the action, the store that holds it, the people who may access it, and the transfers between them. Decide how records are protected at rest and in transit, and how backups are encrypted. For example, restic encrypts repository data with AES-256 in counter mode and authenticates it with a Poly1305-AES message authentication code, which supports integrity of backup copies. The output is a custody diagram and a protection standard that your audit log controls (AU-9) can reference.
Configure the system to record the binding
Turn the design into configuration. Enable signing or authenticated submission for the covered actions, bind each record to the identity from the register, and make sure the record includes the time, the action and the outcome in line with AU-3 content expectations. Where a process acts for a person, record both the process identity and the person it acts for. Keep configuration under change control so later edits are visible. The output is a configuration baseline with the settings and the exported records that show each binding in effect.
Test that each record traces to one identity
Run controlled test transactions for each covered action, then attempt to trace each resulting record back to a single identity using only the stored evidence. Also test negative cases: a shared or expired credential, a record with a missing identity, and an attempt to alter a stored record. Record which tests pass, which fail and the fix applied. Testing is the closest match to the assessment method that exercises the mechanism itself. The output is a test report with the test cases, the results and the retest evidence. Confirm the scope of testing with your assessor before starting.
Document the procedures and each enhancement decision
Write the procedures that operators follow to verify and retrieve non-repudiation evidence, including how credentials are issued, rotated and revoked, and how a record is exported for an investigation. For each AU-10 enhancement in SP 800-53 Rev. 5.2.0, record whether your baseline requires it, whether you implement it, and the reason. Only four enhancements are current, and SP 800-53B selects none of them for the low, moderate, high or privacy baselines, so your decision depends on your own risk and contractual requirements. The output is a procedure set and an enhancement decision record, both linked to the system security plan.
Hand the evidence to the independent assessor
Package the register, binding decisions, custody design, configuration baseline, test report and procedures into one evidence set, indexed to AU-10 and its assessment objects. Walk the assessor through the trace from a sample action to its identity, and keep the evidence current as credentials and systems change. Your organization owns the control and makes the determination it can support, while the independent assessor examines the evidence and issues the assessment result. The output is an evidence index and a sign-off by the control owner that the package reflects the operating system.

Which evidence passes an AU-10 assessment

An assessor testing AU-10 looks for a chain of artifacts that connects a documented policy to a working mechanism, to records tied to individual identities, and to the protection of those records afterward. The cards below cover six artifacts, who should own each one, and how often it should be refreshed between assessments.

Audit and accountability policy and procedures

The written policy and procedures are the first thing an assessor examines for AU-10, and they should name the actions that must be attributable, such as creating, sending and approving information. Assign ownership to the security governance function, with the system owner contributing the procedural detail. Review the document at least annually and after any change to signing, identity or logging tooling, and record the review date and approver so the version history is provable.

System security plan entry for AU-10

The system security plan should state how the system provides irrefutable evidence of defined actions, which components implement the capability, and who is responsible for operating it. Entries that describe a mechanism without naming the components tend to fail review. The compliance lead owns the entry and the system owner confirms it matches the deployed design. Update it whenever the signing, certificate or logging architecture changes, not only at the scheduled review.

Configuration exports for the non-repudiation mechanism

Exported settings show the mechanism that binds an action to an identity, such as certificate issuance settings, signing key policies, certificate lifetimes and which services may request credentials. Export them from the running system rather than copying from a design document, and store the exports under version control so changes are visible. The platform engineering team should own the exports and refresh them after every configuration change, with a documented review at least quarterly.

Sample records tied to individual identities

A sample of records shows that a defined action can be traced to a specific person or to a process acting for that person. Pull the sample from production or a representative staging environment, and confirm each record carries the identity, the action and a reliable time reference. Assessors will test whether a record can be disputed, so check that a user cannot approve or send under another identity. The audit operations team should draw the sample and refresh it before each assessment window.

Walkthrough test results for defined actions

Test results from a walkthrough show that the system actually produces irrefutable evidence when someone performs a defined action. Pick a representative set, such as creating a document, sending a message and approving a change, then record the steps, the evidence produced and whether a verifier can validate it independently. Keep the test scripts and results together with the date and tester name. The security testing team or an internal assessor should own them, and rerun the walkthrough after major changes to the signing or identity components.

Custody and access logs for records

Custody and access logs show who could read, change or delete the non-repudiation evidence and whether any such access occurred. Assessors use them to confirm that the evidence itself has not been altered, which supports the claim that it is irrefutable. Confirm that these logs are protected under the audit protection controls and reviewed on a defined schedule. Assign ownership to the security operations function, and check the logs at least as often as the review frequency set in the audit review procedure.

What meeting AU-10 costs in money and effort

This table breaks the cost of meeting AU-10 into its 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 no figures appear here; ask for a written, scoped quote to get numbers for your environment.

Cost component	One-time or recurring	Who is paid or who carries it	What drives it up or down
Tooling and licenses	Recurring	Software vendor for commercial logging, signing or PKI products	Number of systems and identities in scope; open-source options can remove license spend but not upkeep
Identity binding and records design	One-time	Implementation partner or internal engineers	Number of identity sources, signing workflows and approval paths that must be bound to records
Engineering time for PKI and signing	One-time, with ongoing changes	Internal platform or security engineers, or an implementation partner under a fixed scope	Whether an internal CA such as FreeIPA's Dogtag-based CA or OpenBao's PKI engine is already in place
Evidence upkeep	Recurring	Control owners and system administrators	Frequency of key rotation, certificate renewal, log review and change to signing workflows
Chain of custody procedures and testing	One-time build, recurring test	Internal staff with independent testers or reviewers	Number of record types that need custody tracking and how often they are retested
External review or testing	Recurring at the frequency you set	Independent assessor or testing firm	Depth of scope and whether the assessor is engaged for readiness or formal assessment
Auditor sampling and assessment	Recurring at each assessment cycle	Independent auditor or assessor, who issues any report	Number of samples the assessor selects and how well evidence is already organized
Retention and storage of signed records	Recurring	Internal infrastructure or cloud account owner	Volume of signed records and the retention period your organization or regulator sets

Which open-source tools can support AU-10 evidence

AU-10 depends on binding actions to identities and keeping the resulting records intact. The four tools below each address one part of that chain: certificate issuance, short-lived service identities, protected stored content and tamper-resistant backups. None of them is a complete answer on its own, and the organization still owns the policy, the logging design and the evidence it presents to an assessor.

FreeIPA certificate authority

FreeIPA is licensed under GPL-3.0-or-later and includes an integrated certificate authority based on Dogtag for issuing and managing certificates. For AU-10, the useful question is whether certificates can be tied to a specific user or host identity, so that a signature or signed action can be attributed to that identity. Check how enrollment is approved, how keys are generated and stored, how revocation is recorded, and whether the directory records that link identity to certificate. Confirm the fit with the FreeIPA project and with your own identity architecture before relying on it.

OpenBao PKI secrets engine

OpenBao is licensed under MPL-2.0. Its PKI secrets engine issues dynamic X.509 certificates, so services receive certificates without someone manually generating a key and certificate signing request and waiting for a CA to sign it. For AU-10, this helps tie a service's actions to a short-lived, identifiable credential and reduces shared or long-lived keys. Ask how issuance requests are authenticated, how the signing role is restricted, how certificate lifetimes are set, and whether issuance events are written to logs that feed your audit trail.

Nextcloud server-side encryption

Nextcloud is licensed under AGPL-3.0-only. Its server-side encryption protects file contents at rest on local and external storage, with keys kept on the server. It does not encrypt file names or folder structure, so metadata remains visible to anyone with access to the storage. This control protects confidentiality of stored records. It does not prove who created, sent or approved a file, so it cannot stand in for AU-10 evidence. Pair it with application logging and signing processes, and confirm the key handling and metadata exposure with the Nextcloud documentation and your own deployment.

restic encrypted backup repositories

restic is licensed under BSD-2-Clause. All data it stores in a repository is encrypted with AES-256 in counter mode and authenticated with a Poly1305-AES message authentication code. This helps preserve records and detect tampering of backup content, which supports the integrity of evidence held for later review. It does not establish who performed an action, and it does not replace protected audit storage. Confirm how repository keys are managed, who can delete or rewrite snapshots, and how restores are tested, using the restic references and your own backup design.

Who owns AU-10 and what a partner or auditor does

Your organization owns AU-10. The control is part of your system's security and privacy program, so the accountability for which actions need irrefutable evidence, and for keeping that decision current, stays inside your organization. Your team sets the policy, decides which business processes (such as approving payments, signing contracts or changing access rights) must produce non-repudiation evidence, and accepts the residual risk when a process falls short.

Action selection: decide which creation, sending, receiving and approval events need evidence that a specific person or process performed them.
Policy and procedures: own the audit and accountability policy and the procedures that describe how records are produced, protected and reviewed.
Records accountability: name the owner of the audit records and the people who can explain them to an assessor or in litigation.
Identity decisions: approve how identities are bound to actions, including which accounts may act for a service or a process.
Sign-off: accept the system security and privacy plan and any plan of action for gaps.

Before engaging anyone, confirm internally which processes your legal and compliance teams consider sensitive enough to need this evidence.

Where AU-10 programs usually fall short

AU-10 only holds up if the system can tie a recorded action to one identifiable person or process, and show that the link has not been broken. The gaps below tend to appear together: identity is lost in shared accounts, keys are not managed, and the evidence is assembled after the fact rather than produced as the system runs.

Shared accounts break identity binding

When several people log in with one administrator account, a recorded action proves only that the account acted. AU-10 asks for evidence that an individual, or a process acting for an individual, performed the action, so shared credentials defeat the control at the point of recording. Check whether every privileged and approval-capable action traces to a named user through individual credentials, and whether break-glass accounts have a documented check-out and check-in record. Confirm this with a sample of approvals taken from the system itself, not from the policy.

Signing keys without custody records

A digital signature is only as strong as the control over the private key that made it. Many programs cannot say who generated a signing key, where it is stored, who has used it, or when it was rotated or revoked, so an assessor cannot separate a valid signature from a forged one. Record key generation, storage location, access approvals, rotation dates and revocation events. Issuing short-lived certificates from a managed certificate authority, as described in the OpenBao PKI documentation, can reduce how long any single key stays valid.

Logs that omit the acting identity

Many systems record that an action occurred, such as a document being approved or a record being sent, but not which identity performed it, or the record names only a session or application ID. That gap makes the audit trail unusable for non-repudiation, even when logging is enabled. Review a sample of records for each defined action and confirm the user or process identifier, the time, and the outcome are present. Logging content requirements under AU-3 are the natural reference for this check.

Service accounts acting for people

Automation frequently performs actions that a person authorized, such as submitting a payment file or approving a change after a human reviewed it. If the service account is the only identity in the log, the record shows that software acted but not who delegated the authority. Maintain a delegation record that links each service identity to the person who approved its scope, the actions it may take, and when that approval ends. Test by tracing one automated approval back to its authorizing human.

Policies that do not name actions

A policy that says the organization maintains non-repudiation is not enough for an assessor to test. Programs need a written list of the actions that require proof, such as approving a transaction, releasing software, signing a contract, or changing access rights, along with the evidence required for each. Without that list, engineers cannot configure the system to capture the right records and reviewers cannot confirm coverage. Map each listed action to the system component that records it and to the owner who reviews it.

Evidence gathered only at audit time

Teams that prepare for an assessment by collecting screenshots and exports in the weeks before testing often find that the underlying records were overwritten, were never retained, or cannot be shown as unchanged. AU-10 evidence should be produced continuously and protected in the same way as the audit records it supports. Schedule periodic extracts of signing and approval records to a protected store, test that a sample can be restored and verified, and keep a record of who exported what and when.

Questions buyers ask about AU-10 cost, effort and outside help

How much effort does AU-10 take, and what drives it?

Effort depends mainly on how many systems fall under the high baseline, how many defined actions need irrefutable evidence, and how much identity and signing design already exists. NIST does not estimate compliance costs, so no figure is given here. The main drivers are:

The number of actions in scope, such as creating records, sending messages and approving information, and how many systems perform them.
Whether users and services already have strong, individually attributable identities.
Whether signing keys and certificates are issued and retired through a managed process.
The volume of plans, configuration records and test results an assessor must examine.

Ask any implementer for a written scope that breaks effort down by system and by action, so you can see which parts are new work and which parts reuse existing controls.

Can our in-house team meet AU-10 without an outside partner?

Yes, an internal team can implement and evidence AU-10 if it has the skills in identity management, public key infrastructure and audit logging. The organization owns its controls, so the policy, the owners and the accountability for the outcome stay internal either way. An outside partner can prepare systems, configure signing and identity components and assemble evidence, but it does not issue assessment results. Only an independent assessor can do that. Consider a partner if your team lacks certificate lifecycle experience, if the work competes with other programs for the same engineers, or if you want an external check on the design before the assessor arrives. Confirm which of these tasks you will keep in-house before you request a quote.

How long does AU-10 work usually take to complete?

No researched duration is available for AU-10 work, so confirm the timeline in a written scope rather than relying on a generic estimate. The schedule depends on the dependencies that come first: the identity system, the certificate or signing design, the logging pipeline and the assessor's calendar. Ask the implementer to list each milestone, the party responsible for it, and what must be finished before the next step begins. Most engagements at DeployOpen are fixed-scope, which means the scope, deliverables and timelines are agreed in writing before work starts. Use that written plan to compare offers, and ask how changes to scope would affect the schedule.

What does AU-10 require from our staff day to day?

AU-10 needs named owners and staff who can explain how the system proves who did what. Assessors interview system and network administrators and system developers, so those people must be able to describe the configuration and the design decisions. In practice, expect to provide:

A named owner for signing identities and the key or certificate lifecycle.
Documented procedures for issuing, renewing and revoking the credentials used to bind actions to people or processes.
Staff time to walk assessors through the mechanisms and to supply test results.
Ongoing attention after the assessment, because changes to identity or signing components can affect the evidence.

Identify these people early so their availability is part of the written scope.

Is AU-10 part of the NIST privacy baseline?

No. SP 800-53B selects AU-10 for the high security control baseline but not for the privacy baseline. The privacy baseline applies regardless of impact level and covers privacy-specific controls, so it does not bring AU-10 in on its own. If a system is categorized at the high impact level, AU-10 applies through the security baseline. Systems that process personally identifiable information at lower impact levels should be checked against the current baseline profiles, because the privacy baseline and the security baseline are separate selections. Confirm the category of each system with your assessor before you assume which controls apply.

Does AU-10 require any control enhancement to be implemented?

The baselines do not require one. AU-10 has four current enhancements after AU-10(5) was withdrawn, and SP 800-53B does not select any of them for the low, moderate, high or privacy baselines. The enhancements address stronger identity binding and chain of custody, which become important when actions are disputed or when a contract or regulator asks for more than the baseline. Your risk assessment, your tailoring decisions or a customer requirement could still add one. Confirm this with your authorizing official or the party that sets the contract terms, and record the decision in your plan, so the assessor sees why each enhancement was or was not adopted.

Who issues the AU-10 assessment result, and what does DeployOpen provide?

An independent assessor or certification body issues the assessment result. The assessor examines the policy, the system security plan, the design documentation and the configuration, interviews the people involved and tests the non-repudiation mechanisms. DeployOpen plans, implements and documents the systems and prepares the evidence the assessor will review. DeployOpen does not issue audit reports, attestations or certifications. The organization remains responsible for its controls and for accepting the assessor's findings. Ask any partner to state this division of roles in the written scope, together with the deliverables you will receive and the evidence packages they will prepare.

Which open-source tools can help produce AU-10 evidence?

Open-source public key and identity platforms can produce parts of the evidence AU-10 asks for, mainly by controlling how certificates and identities bind to people and processes. FreeIPA includes an integrated certificate authority based on Dogtag for issuing and managing certificates. OpenBao's PKI secrets engine issues dynamic X.509 certificates, so services receive certificates without a manual key and signing request workflow. Both can supply configuration records and logs that an assessor can examine. Confirm that a tool supports the exact signing and approval workflow you need, because the platform's capabilities must match the actions in your scope. The FreeIPA project site describes its components.

How DeployOpen scopes and prepares AU-10 evidence

DeployOpen plans, implements and documents the self-hosted systems that produce AU-10 evidence inside your own infrastructure. We prepare the systems, configuration and evidence for your assessment, while your organization owns the control and an independent assessor reaches the conclusion.

How we scope

The written scope names which systems must bind actions to identities and which actions, such as approvals and message sends, need irrefutable records.
Scope lists the signing, certificate and identity components involved, and the systems that will hold the resulting evidence.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure identity binding so each defined action traces to an individual or to a process acting for a named individual.
We set up certificate issuance and key handling so signed records can be verified independently of the platform that produced them.
We document the mechanisms and test them against the defined actions, keeping configuration settings and results ready for examination.

How we hand over

You receive configuration documentation, mechanism descriptions and test records mapped to the AU-10 assessment objects.
Handover covers the procedures your administrators and developers need to operate and verify non-repudiation mechanisms over time.
Your organization decides whether the evidence satisfies AU-10, and an independent assessor issues any report or conclusion.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover re-testing when signing components, certificate authorities or the audit records they protect change.
We confirm with your team which controls the evidence touches, including AU-9 and related SC controls, before changes are made.