Yes he confirmed it yesterday with one of the EMET developers (while at Black Hat): EMET GUI is in .NET but the engine is a native code (C/C++). EMET purely works on the user level and has no Kernel component. Like AG’s Guarded app concept it is recommended for risky applications but not for all applications. He further commented (this is my expert - not Microsoft): AG has no conflict with EMET when properly configured and we welcome EMET as probably the best HIPS technology. But there are multiple cases in the past including for IE protection, out of the box EMET protection could not deter unless a particular (“signature”) EMET configuration suggested per the attack. Even then such remedy usually broke the functionality of the underlying application for the sake of protection. So in such cases until EMET remedy is provided still AG will effectively protect users. EMET is a great technology, not for every user, not for every company as the overhead of maintaining compromise between “breaking” for the sake of stringent protection vs application productivity is always a challenge as EMET in edge cases (which happens to be the case in the recent 0-day attacks on some applications including IE) relies on nondeterministic thresholds/heuristics controls. We still believe it is a great technology and we applaud Microsoft’s efforts to make this technology available for advanced users. But ultimately it is not a one-for-all tool as a 0-day protection by AG is still important protection step. AG does not compete with EMET nor it attempts to replace it. At the same time EMET cannot replace what AG offers as effortless 0-day protection. Now can we stop talking about EMET in the AppGuard thread? Really, I'm just kidding!!!! These are great discussions and we welcome them.