While it may be possible to use Scrum, queue-based frameworks are generally a better fit for support processes. Queues should be designed around response times rather than solution lead times for best results.
Capacity and work-in-progress (WIP) limits should also be clearly articulated. You should also have a clear plan of how to handle situations where capacity or WIP limits are insufficient to meet your defined Service Leval Agreements (SLAs).
Agility and Fixed Guarantees
You can certainly adopt agile practices for maintenance, but SLA guarantees per se are (by definition) not iterative and not agile. Agile frameworks are about improving estimates and continuous process improvement; they are not designed to guarantee fixed lead times.
With that said, while Scrum is a project management framework, an agile framework like Scrum or Kanban can certainly be used for support with a large number of caveats. Scrum in particular is largely focused on estimating capacity based on time-boxed iterations, which isn't particularly conducive to dealing with high-priority issues that arise mid-Sprint. Handling support while a product is being developed is certainly part of Scrum, but I wouldn't recommend it for a support-only process.
Queues and WIP Limits
Kanban is somewhat of a better fit for support processes, insofar as it's queue-based. As maintenance issues are found, they are enqueued. With Kanban, you have the flexibility to design queues that map to your service level agreements, but again with some caveats. In particular, Kanban is optimized for queues with predictable variability in story size. Support and maintenance tickets would therefore need to be aggressively managed and decomposed into bite-sized pieces in order to maintain flow.
In my personal experience, an SLA should guarantee response time rather than promising a fixed time-box for results. With Kanban, that could be accomplished by adding a few queues such as "Triage" and "Respond to Customer", and ejecting or pausing work-in-progress (WIP) items from other queues when your high-speed queues are full.
Managing Expectations When Capacity is Exceeded
It's important to understand that there's no free lunch. Regardless of your methodology, your team needs to have sufficient capacity to manage the maximum WIP you are expected to handle within your SLA. If you exceed those WIP limits, then you must have a defined process for managing your WIP limits. This may be via transparent communications with your internal or external customer, or (in some environments) may be handled as business risk with attendant costs such as customer refunds. No matter how you handle it, or what your planned capacity is, it is always possible to exceed your queue size or WIP limits, so you must decide ahead of time how to handle that.