Larry Osterman wrote about “Why is Control-Alt-Delete the secure attention sequence (SAS)?” back in 2005. The answer is so short that there is no real need to summarize it, although I am eliding a few side notes.

When we were designing NT 3.1, … we needed to have a keystroke sequence that couldn’t be intercepted by any application. …

It turned out that the only keystroke combination that wasn’t already being used by a shipping application was control-alt-del, because that was used to reboot the computer. And thus was born the Control-Alt-Del to log in.

So there you have it, the reason why Ctrl+Alt+Del was chosen for the secure attention sequence.

Most likely on DOS there was no real technical reason why you couldn’t possibly have caught Ctrl+Alt+Del and used it for some other purpose, but nobody in their right mind would have done that in a DOS application since it would break so much of users’ expectations of how their computers worked. Note that Windows 3.x (when running in 386 Enhanced Mode; I don’t think it did so when running in Standard Mode, and certainly not Win 3.0 in Real Mode) caught and handled Ctrl+Alt+Del, which demonstrates that it could be done even when running on top of BIOS + DOS. Probably the code that did the grunt work for that was just a few assembly language instructions, hooked to the appropriate interrupt vector, which looked for DEL with the CTRL and ALT modifiers set, doing a bit of magic if it found that particular combination.

As for simulating it, I’d go with “why would you want to?”. I do recall reading somewhere (maybe it was at Larry Osterman’s blog, maybe it was somewhere completely different) that technically the secure desktop is a separate session started and maintained by the Windows initialization code, and thus inaccessible to any non-privileged process. That said, apparently there is a SendSAS() function in SAS.DLL (which on Win7 is in System32) wich will simulate the user pressing Ctrl+Alt+Del; see SendSas Step by Step for a short code example. Caveat: I haven’t tried that one myself.

Why it cannot be intercepted:

1. Because it would be a huge security risk. Imagine an application which launches at logon. It shows a false logon screen to the user and invites the user to enter a password. To avoid this scenario, you often have (in business environments or on Windows Server) to press Ctrl+Alt+Delete before logging in; this ensures that you’re not entering your password in a false logon screen.

2. Because Ctrl+Alt+Delete is known for being the last resort where a full-screen application hangs and you cannot switch to another one (Alt+Tab) or to the start menu (Win). If Ctrl+Alt+Delete is intercepted too, the only way to exit such application would be to power down/unplug/force reboot the PC.

Why it cannot be simulated:

1. Because you don’t need it. You can already do whatever you want with the user session (given enough privileges), including the logoff.

2. Probably because it’s difficult to implement. Since those keys cannot be intercepted, it might be that for the same reason, a piece of software (aside drivers) cannot emulate those keys.

In a comment to another answer you said the answer explained why it shouldn’t be intercepted, but you are asking why it can’t, not why it shouldn’t be intercepted.

Maybe I’m pointing out the obvious, but it can’t be intercepted simply because that’s how windows was designed. The OS obviously intercepts it, and it simply refuses to pass that event on to applications. It was a design decision by the makers of the OS.

The answer is that it can be intercepted — you just have to do it before it gets to Windows (i.e at the driver level or the firmware of the device). The reason you can’t intercept it once the OS has it is because the OS doesn’t allow it.